The bottleneck was never the code(thetypicalset.com) |
The bottleneck was never the code(thetypicalset.com) |
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
at the same time, context poisoning is a real cognitive problem for humans too and I can't tell you the number of times I've seen irrelevant details become a drag on execution. my fear is that having too much context will only cause bikeshedding and a revisiting of prior decisions.
frankly, our organizational structures were already pretty good at creating mechanisms for eliciting the right implicit context at large scales. it is possible that we're just going to come up with the same mechanisms from first principles...
> Not just “this module exists,” but “this module is weird because the migration had to preserve old behavior,” or “this benchmark matters because a previous optimization silently changed the distribution.”
The thesis here is that an LLM will document code better than a human (although based on human artifacts), since churning through huge quantities of text is what they are good at.
A few thoughts:
1) Yes, an LLM may be able to pull comments out of commits and PR comments and put them back in the code where they belong, but I question how often a developer too lazy to put a vital comment in the code would put it in a commit message instead!
2) "The truth is in the code" has always been true, and will always remain true. If the comments differ from the code, the code defines the truth. Pulling comments from stale external documentation and putting them in the code does more harm than good.
3) Comments that can be auto-generated from the code don't add much value (lda #1; add one to the accumulator).
4) Comments about the purpose or motivation of the code, distinct from 3), such as the "we had to preserve backwards compatibility" example, or "this code does this non-obvious tricky thing because ...", are where the value is, but the LLM is highly unlikely to be able to discern any unwritten motivation by itself. If the human developer left a comment somewhere then great (assuming it is still relevant)
Most of the discussion we see about LLM coding is how fast it can churn out thousands of LOC on a greenfield project, or how good they can be at finding bugs, but neither of these are very relevant to the main job of developers which is maintaining and extending existing codebases. It would be lovely if most projects were greenfield, but they are not.
In any large project that has been maintained over a few years or more, there will inevitably be an ever growing accumulation of bug fixes and patches for specific issues that have been discovered in production, likely poorly documented and out of sync with any original documentation that may have existed (which anyway tends to be more idealistic and architectural in nature, not capturing these types of post-deployment detail and special cases).
The natural tendency of an LLM is to want to rewrite code to match the statistics of what it was trained on, and they need to be reigned in via prompting to resist this and not touch more code than is minimally needed for what is being asked. Of course asking an LLM to do something is a bit like asking a dog to do something - sometimes it will, and sometimes it won't. I expect over the next few years we'll be experiencing, and reading about, more and more cases where LLMs have introduced bugs and regressions into mature code bases because of this - rewriting code that should have been left alone. The general rule is that if you are tempted to rewrite something you better first understand why it was there, coded the way it is, in the first place.
I can't help but compare the current state of "AI" (LLMs) to the early days of things like computer speech recognition or language translation when they were considered amazing, and everyone was gushing about them, but at the end of the day the accuracy still wasn't good enough to make them very useful - that would take another 10-20 years.
Another historical lesson/perspective would be expert systems which at the time were considered as AI and the future of machine intelligence (the Japanese "5th generation systems" were going to take over the world, CYC promised to offer human level intelligence), but in retrospect were far less important. It won't be until we move on from LLMs to something more brain-like, deserving to be called AGI, that LLMs will be put in their historical perspective.
At the moment DeepMind seems to be the only one of the big labs admitting/recognizing that scaling LLMs isn't going to achieve AGI and that "a few more transformer-level breakthroughs" are needed. Hassabis has however talked about LLMs (GPTs) still being a part of what they are envisaging, which one could either regard as a pragmatic stepping stone to real AGI, or perhaps that they are not being ambitious enough - building something that still needs to be spoon-fed language rather than being capable of learning it from scratch.
This is the key line right here:
> Negotiating, agreeing, communicating the shared picture of what we are building has become the work. And it’s just as hard as it was.
But if software (via code) is what we ultimately produce and sell, how did we get here? The main reason is the following lemma:
Lemma A: "The loss of fidelity of what can fit in any one person's head scales superlinearly (exponentially?) as the scope of work scales up." Or more colloquially: "It is impossible to fit a large scope of work in any one person's head." This is largely because any non-trivial task is a fractal of smaller dependencies.
The chain of logic to today's situation is then obvious:
1. Writing code requires humans who are slow and expensive.
2. To do large things we need large groups of humans.
3. As the number of humans grows (like beyond 5? 10?) it becomes impossible to keep them aligned, largely because Lemma A.
4. We need to coordinate these humans, so: enter managers!
5. But even a manager can't manage too many people and coordinate with all other managers because, again, Lemma A. Enter hierarchy!
6. As the size of the organization grows, so does the coordination overhead (exponentially, if Google AI overview is to be believed) until as,that quote surmises, the majority of the work is just that.
7. Coordination costs (or "Conway Overhead" as I call them) are very well understood in the literature, but this also brings in undesirable dynamics like bureaucracy, politics, organizational metrics (also due to Lemma A, but now triggering GoodHart's law!) and eventually territorial disputes and empire-building. Lots of friction and subtle mis-alignments.
As you can see the overhead scales superlinearly with the number of leaf workers added. And for the same reason, once the leaf workers are decimated because one worker can now do the work of a whole team, the entire organizational overhead above that is gone, which is also a superlinear change! Assume a conservative 2:1 reduction in ICs and a 1:5 manager:reportee ratio, a simplistic hierarchy that was:
1 CEO -> 5 VPs -> 25 Dirs -> 125 Managers -> 625 ICs
now becomes something like:
1 CEO -> 12 SVPs -> 60 Sr. Managers -> 310 Sr. ICs.
Not only did that eliminate 300 ICs (mostly junior I suspect) it took out 60 managers and removed an entire layer of Directors from the hierarchy! Worse, the leaf-layer will probably get decimated 5:1 not 2:1, and this will also eliminate coordination-specific roles like Program Managers. The rest of the hierarchy is much fewer but mostly more experienced (or politically savvy) people. They will be paid more, but not superlinearly more, of course, what do you think this is, socialism?
It's very much a pyramid scheme of cards built on that one bottleneck. And this bottleneck applies for pretty much all knowledge work. Once that bottleneck opens up, everything collapses. This is why I fear that the coming job changes are going to be much more disruptive that people realize, something I'm extra concerned about as a parent of high-schoolers.
Insane amount of bureaucracy, paperworks, and how we are missing deadlines so we write shit code that the quick and dirty solutions were never replaced.
Algorithms and data structures therefore are more like helping you utilize the machine economy better, but it doesn't have any meaningful impact on the social aspect of it. That's a hard lesson I had to learn from my two previous job, though now I'm considering starting my own small business just to make a little bit of living enough to survive.
But now my ADHD kicked in and is still lazy and I had so many concerns whether the market validation is great, how to deal with situations if I broke customers stuff, how to gain (and hopefully not regain) trust if any bad things ever happen, what if I want to go vacation and suddenly the server broke and got code zero (the highest level of alert I termed internally, when you had alertmanager flashing everything red, network storage is down, corruption happened) during a trip to Bahamas.
I'm still in the watershed of thinking really to do this or not, but the job market is filled with ghost jobs that are not worth my time either, I'm basically "dead locked" right now and had to make a decision quick.
Either choice is fucked for me, as I started to notice after going to work, despite I got some really interesting ideas in tech, but I'm not a charismatic person so I can't really make those idea to fruition, because no one wants to listen to me and implement it together, so I'm pretty sure it is impossible for me to be a great leader (tech lead probably, but CEO level of leadership and coordinator and manipulate the grand scheme of thing, nah, I pretty much can't do).
Now the problem is, even if I'm pretty sure to get fucked, you should choose the one that inflicts minimum pain to you. So far having my own business seems like a less painful to die and bankrupt, and I'm preparing to sell off some of my stuff to get a last dip of my fortunes and have fun. Will see how it looks. Bankruptcy is nothingburger in this modern society perhaps.
Now you see how the bottlenecks can't even be the code anymore and even goes beyond code, despite having the same core template: I don't even have to code, to repeat the same "quick and dirty" kind of mindset in another domain, in another instance. That's something LLM, heck not even AGI can solve: decision-making based on situations with limited time and resources, and it can be personal or organizational or even structural.
This is very much not going to be solvable by a bunch of lines and statements and expressions, but it really need some time to dig in and compromise. Pick your kool-aid and drink it
I hate that em dashes have been killed by AI as well. Hundreds of years ago Charles Dickens was using them in his novels and today someone will read his books and in ignorance actually think AI wrote it.
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.
Never experienced this at a job in 30+ years, and that includes my first jobs in fast food. If you experience this at work, find another job. This isn't normal. It's extremely dysfunctional in fact.
Thing is, this job market is hell. There are folks who have to choose between the abuse or making rent, which is why we need stronger incentives for organizations to discipline said abuse rather than let it permeate because existing penalties lack teeth.
For him, the bottleneck very much was the code. He still doesn't know any programming.
I want to say that his ability here has been accelerated by orders of magnitude, but without AI he couldn't have done it at all, so it's actually a divide by zero situation.
(Yeah, he could have just learned programming... and audio engineering... and the specifics of JavaScript ... and the web audio API, and the DOM, and WebGL, and his demo would be ready in like, 2030.)
FizzBuzz was a litmus test that showed how hopeless the average developer was. Coding interviews were the real test of programming ability. Now we're being told none of that ever mattered for real?
We should just admit that the game has changed (possibly, I'm not 100% convinced). Code WAS the bottleneck and coding ability was the bottleneck, but it may not be going forward.
- Moving to a newer and more modern test library
- Refactoring my data layer so it's easier to read, based on years of organic changes that need to be baked in and simplified
- Porting some functionality to another language to vastly improve performance
I agree with the overall sentiment, but having an agent at my finger tips who can really crank out large-scale, involved code changes is unclogging quite a few backburnered todos lately for me.
Is this actually true? Maybe in a widget factory. I think it’s an anti-pattern for the new world.
When you look at places that are shipping at insane pace (like Anthropic) the secret is not accelerating the writing down of a roadmap and we’ll groomed backlog, it’s empowering smart individuals to run their own end-to-end product improvement loops.
You can slightly reframe the OP by saying “the bottleneck is product ideas”, but “well formed backlog items” IMO frames it as more structured and hierarchical than it should be.
The insane billion dollar companies ship straight to production because they have PMF so anything and everything gets signal.
The same happened with Facebook and Google. And it was always cautionary advice to mimic these giants. It's a bad idea for all the rest of us.
This is like going to a startup as a senior bigtech engineer - if you can’t ship it becomes clear quite quickly.
Regarding the talent dysmorphia issue - the best way I know of getting people to step up is to give them more agency and more accountability. The new world will require that IMO.
I think Google etc are more a story of how much you can get away with when you have a strong monopoly. Their orgs are not shipping fast, nor good at shipping products. (Google in particular is incredible at infra but laughably bad at consumer products.)
I wish I could give you good, brief advice on how to avoid getting downvoted to death before you even get started. There are undoubtedly others who would do a better job. So I'll just say "try really hard not to appear like ChatGPT write your post."
Everything imaginable is being impacted by AI, in expected and in surprising ways. Communities are going to need to put extra effort into things that used to just happen, like welcoming new members. Here's mine.
(I hope I'm not wrong and that you're not actually a spammer. But I think my bet is safe enough. :-)
If I was a scribe at the time I’d be thrilled because of all that extra time available to work on beer productivity metrics.
The issue is that sometimes you don't know what the system should do until you build it.
A design is a hypothesis. Most of them are wrong, in subtle or not so subtle ways.
(Also, as a separate issue, having a group in the first place increasingly adds negative value. If it was ever a good idea to design by committee... it's increasingly expensive to do so, in opportunity cost.)
> Impactful software tends to be written by many humans that need to collaborate.
This was definitely true. Is it still true to the same extent/ in the same way? Not obvious...
The amount of detail required is less these days and the computer is better at interpreting handwavey explanations but the principle still applies.
Whether code is the bottleneck likely depends on the organization. In mine, code is the bottleneck. AI has pushed it so validation is now the bottleneck. If it is such that the devs are "middlemen" such they can't spec things, then I think whoever can spec things is likely the bottleneck.
Here's Robert Martin saying non-determinism in AI is ok:
https://x.com/i/status/2044440457422549407
Who wants a non-deterministic banking app?
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.
This is kind of a straw man. I suspect people say that tongue in cheek.
Good programmers try to make their code clear and easy to understand. They add comments to clarify, specially their whys.
The problem I have with documentation is that you end up with mountains of documents over time about a lot of things that are no longer true and many times contradictory. The only solution I have seen is making sure that documents have owners that update them periodically.
The shrinking that property based testing does when it finds an issue is kind of what we need for specs/context.
Now if your design / requirements are wrong who cares? Tomorrow you will have a brand new stack.
Stuff like this is ridiculous and comes off as frantically trying to save your ass. Its pretty obvious at this point that we will just throw more matmuls at it until it can do this or something equivalent.
> Agents cannot do osmosis. They do not get context by being in the room, by half-hearing the planning conversation, or by carrying the memory of the last incident.
At the same time, humans can move up the abstraction ladder faster than the LLMs can. At least, some humans. Agents can produce lots of code. They can also do the entirely wrong thing. The impact of wrong decisions have been massively write-amplified with more and more intelligent LLMs. With earlier ones, it got a sentence or a function wrong, you reprompted, the cost of a mistake was 10 seconds. Now, you can burn hours or even days of work on the entirely wrong thing without a competent human operator stepping in and course-correcting.
The trajectory of agents have been bigger and bigger context windows, bigger autonomy, but at the same time, a bigger blast radius. In this context, I don't think the human experts will be out of their jobs any time soon.
This was kind of the point, its only true for now. I agree with you that this kind of stuff will take longer. I don't think there's probably good training data for it right now. Handling abstractions and course correcting is probably the job now, and it also happens to be exactly the data that we will be typing in our prompts. They'll train on it or something like it.
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.
Take the strawman: even if AI can one-shot basically any application below let's say, 1MLoC, if your prompt is 4 lines, it will generate something. It can't read your mind. If you make proper specs, then you'll get what you want - but many people don't know what they want. And even if they do, they might have contradictions in their requirements, might be asking for something impossible, etc.
In any case, two things can be simultaneously true:
1. Writing code is not the bottleneck, as in we can develop features faster than they can be deployed. 2. It's annoying and disruptive to be interrupted when doing work that requires deep focus.
I think there are small pieces of truth on both sides of the argument, but I find the sudden change to claiming that coding speed doesn't matter to feel half-baked. Coding speed is part of building a product. Speeding it up does provide benefit. There's a lot of denial about this, but I think the denial is rooted in emotion more than logic right now.
That's an organizational issue due to over-regulation, bureucracy, too many stakeholders each with their own irrelevant opinion, etc.
Startups or FOSS projects without the above absolutely can't "develop features faster than they can be deployed", and usually have a huge backlog of bugs and features they'd like to have, but never got around to.
Steering a LLM also requires deep focus. Unless you want to end up on accidentally quadratic or have a CVE named after your project.
Meetings that increases sync between customer and coder are few and precious.
In large organisations ceremonial meetings proliferate for the wrong reasons. People like to insert themselves in the process between customer and coder to appear relevant.
I personally am fond of meetings with customers, end-users, UX designers, and actual stakeholders.
I loathe meetings with corporate busybodies who consume bandwidth for corporate clout.
No, I don’t need another middle manager to interface themselves between me and my users.
Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later? Ah yes, so that we meet our quarterly OKR, and the next quarter's plan that the EM and PM negotiated without me or our customers isn't disrupted and doesn't need adjustment. That would invite reprimand from the director, and the extra work would be terrible for them, I understand.
I'm reminded of this recent thread in which Heroku left the devs in charge and suddenly features that the author had requested for years got implemented: https://news.ycombinator.com/item?id=47669749
This matches perfectly my experience in working in many companies, where in most of them meetings were useless, but in a few places meetings were very useful, depending on how the companies were organized and how the attendance to meetings was selected.
I have seen projects that had to be abandoned without bringing any money, despite being executed perfectly according to the specifications. The reason was that the specifications were wrong because the customers have not thought about describing some requirements and the developers could not ask about those, because of lack of direct communication, while the middle men had no idea about both things, about what the customers might require and about what the developers might need to know.
I am a former Dev turned PO/PM and now CEO, I can tell you many a developers are not fond of those meetings you are fond of and people like myself don't insert our selves where we don't belong, we simply join the meeting and have the vital conversation with the customers/stakeholders whos payments make payroll possible, while the developers refused to.
My team have always commented and liked that I "shielded" them from the none technical meetings and distilled customer needs in our kanban, without them having to go to the meeting. While I agree this isn't the "best way" to do things, I simply have never seen a Dev Team work as the way HN tries to make the role sound "Dev/Eng and the customer is the only thing needed". Would love for this to be the case!
Also for those who think I'm down talking the abilities of my team, we made a company together when we left a huge company we worked for, as Co owners and even now we use same setup is used :)
That comes with real tradeoffs, but I've never regretted that path.
How is it hypocritical?
If in the old world, the very important process that used up a lot of time and benefited greatly from no distractions was the actual writing of code then interruptions for various ceremonies with limited value other than generating progress reports for some higher ups would feel like a waste of time.
That same person in the 'new' world where writing code is very fast but understanding the business and technical requirements that need to be accomplished is the difficult part would then prioritize those ceremonies more and be ok with distractions while their AI agents are writing the code for them.
It's not hypocritical to change your opinion when the facts of the situation have changed.
I’ve noticed this push to try to clothe hypocrisy in made up virtues like intellectual curiosity and mental plasticity a lot lately. All I can think is that it’s some kind of ego satisfaction play people make when their place in the world is threatened.
There is a reason (well, many reasons) that, if I'm working on a creative project with somebody outside a company, we would never think of reaching for Scrum ceremonies or Jira.
It is more than perfectly consistent to complain about that while valuing collaboration.
1. µManagement asking "What have you even been doing?" Now they have a dashboard, and I have a nice record.
2. Protect me from people who wouldn't tell me problems existed, but would tell their managers they were blocked by those problems. Now, the understanding is that if the Jira doesn't exist, then the problem doesn't exist.
3. I use the "On Hold" state of an issue for a clear signal, for them and their managers that I add as watchers, that there will be no progress until whatever requirement is met (question answered, etc). It dramatically decreases response times, and means I don't have to nag them. Goes back to #2, where I can point out that they are blocking themselves.
All these things come into existence because people are so bad at collaborating, but really good at pointing fingers.
It might be easier to collaborate with one other person through email or text message history. Or even two or three people. But beyond a certain point having tickets to track all the conversations about a task becomes invaluable.
The problem rather is: often good programmers have quite good ideas how these problems could be solved, but for "organizational politics" reasons they are not allowed to apply these solutions.
Thus:
Concerning (B): Because they are not allowed to apply their improvement ideas, they are the bottleneck. But being the bottleneck is not the root problem, but rather a consequence of not being allowed to improve things.
Concerning (A): It is indeed often the case that if you simply let someone else do the work, the code quality decreases a lot and in subtle ways. Good programmers are very sensitive (and sometimes vocal) with respect to that - in opposite to managers.
The manager didn't do the work to figure out what a contractor should do before hiring one. Why would they expect that org to plan the exit if they didn't plan the entrance?
Behavior shouldn't be surprising, no?
True, most engineers hate meetings because as your rightly point often there can be too many "types" of meetings - team meting, issue tracking, backlogs, design reviews, triage etc etc. Out of the 7-8 working hours, a senior engineer might be in meetings for 4-5 hrs. Then they bitch and moan that they are spending too much in meetings and not enough time coding. A reason for that is projects often have unclear or even changing requirements along with tight deadlines.
Sure today with AI, code can be produced faster than ever. But the requirements being unclear or always evolving hasn't really changed. Today many non-engineers assume that what they have in mind is straightforward and can be created by AI. That is not true. Unclear requirements lead to unclear results. Garbage in Garbage out. Getting the right input is still the most important part of software. That has not changed. That is the collaboration piece of software.
And sure within the software community there are folks who don't like to collaborate even on requirements, they are more than happy to follow someone's lead. They like their manager/architect to "shield" them and do these tasks for them. These silent warrior type engineers are going to be the most impacted due to AI coding. Because they have no visibility and even if they are 5 rated coders, there is always going to be "But AI can produce code. What else can you do if you wont even collaborate?"
So, it's not very cut and dry. Engineers come in all shapes and size.
No developer was ever unhappy to communicate. But when pointless communication occupies too many long hours, interrupting useful the progress of understanding what could and should be done (by coding, yes, experimenting, getting a grasp of the beast), then yes they became unsympathetic.
I've worked with engineers all over the spectrum in terms of their styles, beliefs, and preferences... and some of them are frankly not very interested in getting out of their comfort zone (like heads down, writing code and being alone), and optimizing for the group rather than themselves.
So yes, they are in fact unhappy to communicate (in a general sense), because of how tedious and uncomfortable communication often is.
I'm not saying it's irrational or immoral, or not driven by the types of past poor experiences you mention, but in my experience it's often pretty obviously suboptimal and highly frustrating to work with.
Who?
There are millions of software engineers around the world. It's quite likely that they have a few different opinions and point of views!
>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
Seems pretty clear to me.
1. Increased velocity makes rituals like daily standup and other comms relatively infrequent compared to how they used to be, so there are fewer touch points now. For example a daily standup might have been occuring several times while someone worked on one feature ticket, but now they can bang out multiple features a day plus some bug fixes, but still only have the daily touch point.
2. AI written code needs to be thought through and planned a lot more than human written, because the machine doesn't go through the same discovery/writing process that a human goes through. It looks superficially similar, but is subtlely and importantly different.
3. Without solid planning and requirements definitions, it's a lot easier for AI to go off the rails and do something you don't ultimately want. That wasn't true for humans writing code because they have a lot of project context knowledge that helps a great deal. AI obviously doesn't have this.
4. With the intense speed of devs now thanks to AI, it's far easier to step on each other and end up with at best merge conflicts, at worst significant deviation in solutions, and often major refactors/overhauls that can make the codebase feel foreign and confusing to devs. Most people have had the experience of stepping away from a project and coming back after a refactor had been done, and realizing that they don't know where basic things even are anymore. It can be unsettling and add a lot of friction.
5. AI can be pretty good (and very fast) at producing documentation and plans, so the "cost" of planning before coding is a lot lower now. That changes the equation of "what is the most important thing to spend my time on to iterate quickly".
- Understanding the problem at hand
- Putting all the pieces together so that they solve the right problem the right way
- Making sure that the solution facilitate future extension and doesn't lead to a ball of mud two months from now... Unless stakeholders want it to be quick and dirty, then making sure they understand the costs/risks
- Planning execution a way that is incremental and testable so that we can build confidence that the system is doing what we expect of it
- if you are in a team, figuring out common dependencies so that those can be done first and unblock parallelism on execution.
Once all that is done and documented, writing the code was easy and fast.
What would sometimes happen is that some unexpected detail or dependency would be discovered as part of the writing of the code and then you are back at the beginning, figuring out how to make everything fit together.
I find that the main confusion comes from people not realizing that those are two different activities and instead calling it all "writing code".
I think one of the things that AI is uncovering is how bad many programmers were/are at this. Sure , they may understand by ref vs. by val, but they can’t or won’t take the time to really understand what needs to be built.
I’ve said for a long time that coding is the easy part, it’s understanding what needs to be built that’s hard. AI has now come along and born that out.
I think the solution will be small (1-5 person) teams where product and engineering sit next to each other and have clear authorization to launch directly to prod at their discretion. The gripes about performative work tracking mechanisms and the realization that non-tech considerations are now the bottle neck are not mutually incompatible.
In fact, deep pipelines don't even need to have bottlenecks to take time. Even still any given meeting could still be a waste of time depending on the meeting.
They are not the same people.
> It's hilarious ... their most essential and sacred activity ... suddenly, and with no hint of shame ... the nakedly hypocritical attitude ... still extraordinary
Calm down the hyperventilating for two seconds, look around, and you’ll immediately see examples of the same group of people who now biTch aNd mOaN about how agentic coding is killing what they love about programming.
It’s interesting to see people either gloat or get incensed at the nerds who like computers in the context of these developments.
[With that said, the specific implementations of such collaboration are often still very painful and counterproductive...]
I don't think it's hilarious, I think it's rather sad to see people so easily trampled by the whims of an irrational market. Generally speaking, we benefit when people stick by their values, and yet we play this awful game where winning means abandoning our values in pursuit of "value" whatever that is.
Another example I can point to is software security. For context, I’ve built and sold two edtech companies that taught enterprise developers about software security .. It didn’t matter how good the training content was .. ouur product replaced boring appsec video training with interactive labs, vulnerable code snippets to hack and fix .. gamification ... leaderboards .. whatever it took so they couldn’t complain about having to watch boring videos .. however the completion rates sucked .. because they just didn’t care regardless of how hard we tried ..
Now post AI .. my Linkedn is full of blogs and think pieces about how important “software threat modelling” and “cybersecurity” are, and how “coding was never the hard part.” ... suddenly, TM, something only a tiny fraction of companies actually practice, is being framed as the real challenge .. and having deep understanding of OWASP / secure design , vulnerable dependencies ..secure architecture ,, is the real bottle neck .. lol
I'm seeing both these beliefs right now:
• Belief A: "I am a skilled professional whose value lies in my unique ability to solve complex problems."
• Belief B: "An LLM can now solve many of these problems in seconds for pennies."
This thread is great at showing how people are rationalizing by moving the goal posts, so to say
I don't think there is any hypocrisy. The error in the analysis is assuming both conflicting opinions are held by the same person. They aren't.
NONE of the activities you mentioned are activities that lead to what article talks about - well designed spec.
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.
I agree with this sentiment https://news.ycombinator.com/item?id=48033534
One of the reasons I liked coding is because it’s easy on a relative basis. Dealing with people, ambiguous requirements, edge cases, business realities, are all the parts that are hard.
American football player Ray Lewis said one time he was paid to go to practice, but he played the games for free. I feel the same way about coding - I was (and still am) paid to deal with everything else.
Unless you sign off on a Looks Good to Me PR and go loiter by the kombucha machine. Then you have other problems.
Personally I find it hilarious that the same people at my company who can't be bothered to write down detailed requirements and are constantly fighting any effort to do research or technical documentation or pay down tech debt are now trying vibe coding and struggling to produce anything useful. Oh you don't understand why you aren't getting the results you expected? Maybe you should try thinking deeper about what you expect before your rush your engineers or, now, your agents.
I think it can be easy to look at code as an asset, but fundamentally it is a liability. Some of the "bottlenecks" to new code are in place to make sure that the yield outweighs the increased liability. Agents that produce more code faster are producing more liability faster. Much of the excitement and much of the skepticism about coding agents is about whether the immediate increased productivity (new features) and even immediate yield (new products or new revenue) outweighs the increased long term liabilities. I'd say we won't find out for another 1-3 years, and of course that the answer will differ in different domains.
From this perspective, attempting to build these bottlenecks into the agentic workflow directly makes some sense. Supplying coding agents with additional context that values a coherent project vision and that pushes back against new features or unconstrained processes would be valuable.
Is this what the article is trying to get at? Is this attempting to make some agents essentially take on product management responsibilities, synthesizing as much as possible into a cohesive product vision and reminding the coding agents of that vision as strictly as possible? Should these agents review new proposals and new pull requests for "adherence to the full picture", whether you want to call this "context" or "vision" or something else?
I think these agents might do an exceptionally good job at synthesizing context and presenting a cohesive roadmap that appears, linguistically, to adhere to the team values and vision. But I'm doubtful that they can have the discernment that a quality manager or team can have. Rapidly and convincingly greenlighting a particular roadmap could do more harm than good.
You're over-simplifying. Code in and of itself is neither an asset nor a liability. The minimal amount of code needed to solve business needs with no additional complexity is an asset with some maintenance liabilities attached (same as how a farmer's tractor is an asset that needs to be maintained), with depreciation if unmaintained (bitrot). Any code used to build unnecessary complexity is pure liability.
A loan is a liability, but you might take one out regardless because you know you can use it to make more money than you'll have to pay back in interest.
That said, I think it's more correct to characterise code as a depreciating asset, as another commenter did.
I've worked at founder-sized startups and $xxb dollar public companies. I've never read a product spec, a pitch deck, or a PRD that describes a solution that, if implemented in the way described, would solve the problem. Building the thing teaches you how it should behave.
Software is a complex, interactive medium. Iterating in the code, with people who understand the problem and care to see it solved, is the only way I've seen valuable products get created. Meetings and diagrams help, but it's not until you write some working software that you know whether you have something.
> 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.
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.
Love that.
I agree, in particular, about the context. That’s where long-retention, experienced, teams pay off.
I managed one of those for decades. When they finally rolled up our department, the engineer with the least seniority, had ten years.
When a team is together for that long, the communication overhead drops to an almost negligible level.
That’s what I find most upsetting about the current culture of mayfly-lifespan employment tenures.
Nowadays, I work mostly alone. I’m highly productive, but my scope is really limited.
I miss being on a good team.
So here we walk around the circle one more time again, voicing our anxieties, talking past each other, waiting for the next opportunity for commentary to come in half an hour.
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.
Most of the team has since passed away, and their code has been long replaced by modern systems, but what stuck with me is that great code is a form of art - where your individual style, insights and personality can be reflected in code for the better. The systems were efficient, responsive, extensible, and a joy to work on, since the team took a great deal of pride in their work. It really is akin to being affected by a clever and insightful work of art. A decade later, and programming became something to "make money" at, which flooded the market with many people who never really had a deep love of programming, and I guess that's ok, but something has definitely been lost along the way.
To your point, it may not be such a bad thing if people started boycotting computer science and it again became more of a calling than purely an avenue to employment.
Agentic tools are "burglary tools" -> Younger folks should not study CS?
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.
Care to elaborate? I don't understand the difference unless you mean code that _is_ the product, being OSS code or code for license.
If you're writing OSS code or software projects expected to be used by others that may have constraints like that, then by all means the code that gets output matters itself. But even still I'd argue that the cost of writing code manually to get there is still a bottleneck.
So, the product vs everything that is needed on the way, but isn’t the core.
CI/CD tooling, template population…. Things you write a use once/use few script for.
I typically end up with a library of tools to deal with repetitive finicky tasks.
A lot of places skip creation and maintenance of decent observability - that's code.
We can now easily use advanced, code heavy testing techniques like property testing - code.
We can create environmental simulations to speed up and improve integration testing - code.
We can lift up internal abstraction levels, replace boiler plate with frameworks, DSLs - code.
The 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`
https://www.thetypicalset.com/blog/grammar-parser-maintenanc...
Solid red dots are articles you've visited.
I don't think this sentence speaks for me. This is the sort of thing I love to do.
Proving that the bottleneck, was, in fact, the code. It's just that the AI wrote it now.
The person who thought "the bottleneck wasn't the code" already had the goal discussed and coherent in their mind.
Code as bottleneck doesn't have to mean "I wanted this feature but it took me many months to finally code it". It is also "I wanted this feature for 2 years, but the friction in sitting down to put it in code and spending 5-10 days on it, etc, put me off".
If the code wasn't the bottleneck, they could just sit and write it themlseves. But, they didn't want to go through the effort and time spent of coding it themselves, as they knew it wouldn't take as little as with the LLM.
(And even when you don't have a clear final spec in mind, the exploratory code+check+discard+retry-new-design, is also faster with an LLM, precisely because the "code" part is).
In other words, the code was the bottleneck.
The post appears AI-generated itself, just with instructions to avoid obvious constructions, which still makes for tedious reading.
The error in the reasoning is that while you can increase your resourcing to tenfold and gain nothing in return, the inverse is not necessarily true.
This is merely speed of development and not the velocity of a company towards higher value. There are many PMs confidently (using the same AI tools), without a clear deep understanding of the user problems or why the requirements will be adopted by their target users (or even who the target users really are), writing these done elaborately.
So yes this will lead to faster end-end execution. But if the product is used or if it sits unused will depend on things beyond the above.
I'm also skeptical that development velocity is so separate from all those other things (context, stakeholder alignment,etc). It's much easier to get actionable feedback when you have a prototype.
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.
The bottleneck is always decision making and human review when multiple humans are involved. This is especially true when we are all trying to build agentic / llm based systems where the outcomes are highly varied and its impossible to write easy tests to automatically check quality or benchmark progress.
I am stuck with an editor based on Eclipse. It’s slow and periodicity pauses or crashes. I am stuck with build jobs that take 15-20 minutes. I am often stuck with web apps that take forever to do a task that should take 50ms max.
The list can go on and on. Every delay is a distraction that shatters my concentration. I still write code at work but I am in management now with dozens of other people and administrative distractions. When the software is slow it become my lowest priority. I don’t care who that impacts because if it really mattered we wouldn’t be held hostage by all this slow syrup of software pulling each of us under.
I really think as code becomes cheap, misalignment between people, teams, and organizations is going to hurt a lot more, especially when everyone is trying to move at break neck speeds.
I also think a big piece of this is human attention and inertia. Aka, why bother doing the hard work to coordinate with others when you can just ship whatever you’re thinking. I think whichever organizations can figure out the human and cultural aspects to this will do phenomenally
Quote from the post article: "To quote Michael Polanyi: we know more than we can tell. Some load-bearing context exists precisely because it was never put into words, and writing it down would change what it is."
Imagine how much knowledge exists only in the heads of software engineers, with code being just a functioning footprint of that "Theory". I know SRE in FAANG who told me that multi-billion system is supported by tribal knowledge within their group, and for years, even pre-AI it was a protection against automation.
I am genuinely curious. I understand where you are coming from, you want to maintain flow state.
How does one effectively load the funnel to support flow state ?
Jira tickets? Requirements documents in some kind of ALM tool?
Having "house rules" on a team that new members must agree to follow tends to flush such people out and they usually exit on their own when their shenanigans get repeatedly called out as violative. Gotta introduce the rules in the interview process and get agreement after they join. Catching them out early is the key.
We had an intervention on one hard case and he rage quit the next day. I don't know why people do that, it's a small world and people talk.
In fairness, given the context those meetings give, it stands to reason that giving that same context to an AI, it can, in theory, still do the same thing as an engineer. But those meetings still need to be had.
If y'all can find that company where the product is entirely developed soup-to-nuts by a single lone-wolf developer, without any other stakeholders or involved parties, by all means join that company! And tell HN about it--many of us would join it, too. But in the real world, development is a messy people-soup and you have to communicate.
We've had systems that induce boilerplate before, and we've had systems that try to cope with that boilerplate before.
Considering the process to be tedious is really not the same thing as being antisocial.
But I have also worked with some who refused to participate in collaboration, they felt their time and ideas superior to others, and there's no excuse for that.
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
The focus is still the code.
The contradictions you see could mostly be variations across individuals rather than hypocrisy within individuals.
(Doubly so for vaguely defined groups, like "kind of engineer".)
Because even if someone is writing design documents you shouldn't be interrupting that process regularly either.
Even if coding was solved, meetings could still be the bottleneck.
You think spending more time on meetings is going to solve anything?
> team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews
Are frequently not:
> [important] collaborative activities
I've always been someone who disliked distractions from my "coding 'flow state' they claimed as their most essential and sacred activity to be protected at all costs" (because, you know, I was getting paid to write code and that's the only way I could actually get it done), but I also loved genuine collaborative activities (as in a small number of people, interacting with each other in a high bandwidth way, to figure something out or get on the same page).
A lot of the activities you explicitly mention are usually literal garbage for actual collaboration.
I'm going to assume you were getting paid to build software that solved problems and created value for your customers and stakeholders. Writing code has always been just one activity that's part of the job, and developers forget that and make statements like this! That's the parent poster's point. I'm not saying it's not an extremely important part of the job, or that people don't often collaborate poorly in ways that take away from the sacred deep work time, but framing it as "I get paid to do X and not Y" is just a highly limiting way to look at or talk about the role.
Also, expect harsh and rude reactions when pointing to big issues that are crystal clear in the middle of the village. Not all truths are warmly welcomed, especially when looking elsewhere feels more comfortable in the immediate experience.
Take care and don’t worry too much: the journey’s short, so remember to also enjoy the good parts.
(A)
Meetings where we discuss whether naming two users in an integration test `u1` and `u2` vs. `user1` and `user2` and whether whoever did the former is so hopeless that they should drop all computer work and go work on a farm, and spend an hour of meaningless and meandering style preferences.
(B)
Higher-level meetings where I can communicate with PMs and customers and CEOs almost on their level f.ex. "Does it make sense for us to have primary/co-borrower roles in our credit products or are all sides equally liable?".
---
With the advent of really good LLMs, meetings of Type A are nearly gone and meetings of Type B have increased meaningfully. I am very happy with that new state of affairs. Are you not?
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).
Similarly, the amount of open source people who previously maintained a hardliner programming meritocracy stance and now pivoted to AI and market AI is exclusively limited to those whose companies are working on AI products. The good ones in that space are decidedly less than 1% of all good ones.
It's precisely because I get swamped with all the non-coding work that agentic coding works so well. And in multiple ways.
- it lets you get back in the flow faster (unless you were used to writing out your inner thinking monologues and reasoning to get yourself back to speed when you come back from a meeting).
- it lets you move faster and take on more on your own, meaning less people needed in the team, less communication/syncing/non-coding overhead.
If you're objective about it, AI coding is going to be amazing for individual productivity. It's probably going to fuck us (developers) over with the reduced demand, lower bargaining power, etc. But just on technical merits it's a great productivity tool.
The models are still not better than me at coding and handholding is required, but the speedups are undeniable, and we're long past the threshold of usefulness. So far all the contrarian takes are either shallow/reflexive pushback because people don't like the consequences, or people working in niche stuff where LLMs are not that great yet. But that has been shrinking with almost every release - in my experience.
I know everyone here writes cutting edge algorithms that were never encountered in the training data, their code is hyper optimized realtime bare metal logic that's used in life or death scenarios and LLMs are useless to them - but most of the stuff I do day to day is solve problems that have been solved before, in a slightly different context. LLMs are pretty good at that.
What even is your point? Are you... mad because the truthiness of a statement can change over time?
half the time you’re going to discover the right decision / path while you’re coding.
focus time went from hammering code to figuring out how to solve the problem. PRs are now how we exchange ideas. meetings are still productivity theater.
My opinion since college (8y ago) was that the best engineers are the ones who treat everything as halfway a people problem, even in low level code.
Since I didn't agree with the premise of the top level post, I was scrolling down as far as possible to get to the second top level comment and yet here I am still scrolling.
From my perspective AI doesn't really accelerate me per se, it's more like the AI helps me avoid getting stuck.
If the "goalposts" represent what people generally think LLMs are capable of, they should be moving, right?
And complex, multi-part, long term efforts like building software and software companies always have numerous obstacles. When one is cleared, you wouldn't expect there to be no more, would you?
Your tone is complaining, but I just see people working in reality.
That's life.
Life changes and us along with it.
"Who Moved My Cheese?"
Agreed, and I also agree that most developers come to this realization with time and experience. When you have a clear understanding of business rationale, scope, inputs, and desired outputs, the data models, system design and the code fall out almost naturally. Or at least are much more obvious.
— Melvin E. Conway 1967
I don't think this comment is fair or grounded. There are plenty of process bottlenecks that are created by developers. Unfortunately I have a hefty share of war stories where a tech lead's inability to draft a coherent and clear design resulted in project delays and systems riddled with accidental complexity required to patch the solution enough to work.
Developers are a part of the process and they are participants of both the good parts and the bad parts. If business requirements are not clear, it's the developer's job to work with product owners to arrive at said clarity.
This is also an organizational problem (bad hiring/personal management). If you put an incompetent individual at the helm of a project, then resources (especially time) will be spent horrendously and you will have more problems down the line. That’s true for all type of organizations and projects.
- I completely agree with you about fundamentally the limitation being the business able to coherently articulate itself and its strategy
- BUT the benefit now is you can basically prototype for free. Before we had to be extremely careful with engineer headcount investment. Now we can try many more things under the same time constraints.
LLMs don't solve any of those problems by itself.
But.. so can your competitors. And that changes the value proposition.
Is this some sort of troll attempt? Like, are you fundamentally misunderstanding the problem with tech debt? This is the equivalent of throwing garbage on the floor and expecting professional cleaners to keep your house clean.
You can produce tech debt faster than you can pay it back, that's the core aspect of tech debt. If tech debt was more expensive in the short term than not doing it, nobody would be doing it.
A labor saving device doesn't reduce or deal with tech debt since tech debt is a decision made independently of the competence of the developers. If you have a company with a tech debt culture, the labor saving device will just let you accumulate more tech debt until you reach the same level of burden per person.
>First consider if you understand what scaling laws are like chinchilla and how RL with verification works fundamentally
Honestly, this tells me that you basically understand nothing, not even chinchilla scaling laws and how RL works. Not only are you trying to brute force the problem, you're listing completely irrelevant factors to the problem at hand.
Chinchilla scaling laws are "ancient" by LLM standards. Everyone who designs a model architecture that is supposed to beat their competitors is pulling out every trick in the books and then come up with their own on top of that and chinchilla scaling laws have been done to death in that regard.
Reinforcement Learning is also a pretty bad example here, because there is no obvious way to encode a reward function to deal with something as ill defined as tech debt. You didn't even say avoid tech debt which would be actionable to some extent, just "systemic tech debt is now addressable at scale with LLMs". I.e. you're implying that if LLMs were to generate tech debt, you can just keep scaling and produce more of it, solving the problem once and for all Futurama style with ever bigger ice cubes.
Is there any reason to believe this? I've only seen the evidence of the contrary so far.
My experience with AI coding aides is that they, generally:
1. Don't have an opinion.
2. Are trained on code written using practices that increase technical debt.
3. Lack in the greater perspective department, more focused on concrete, superficial and immediate.
I think, I need to elaborate on the first and explain how it's relevant to the question. I'll start with an example. We have an AI reviewer and recently had migrated a bunch of company's repositories from Bitbucket to GitLab. This also prompted a bunch of CI changes. Some projects I'm involved with, but don't have much of an authority, that are written in Python switched to complicated builds that involve pyproject.toml (often including dynamic generation of this cursed file) as well as integration with a bunch of novelty (but poor quality) Python infrastructure tools that are used for building Python distributalbe artifacts.
In the projects where I have an authority, I removed most of the third-party integration. None of them use pyproject.toml or setup.cfg or any similar configuration for the third-party build tool. The project code contains bespoke code to build the artifacts.
These two approaches are clearly at odds. A living and breathing person would either believe one to be the right approach or the other. The AI reviewer had no problems with this situation. It made some pedantic comments about the style and some fantasy-impossible-error-cases, but completely ignored the fact that moving forward these two approaches are bound to collide. While it appears to have an opinion about the style of quotation marks, it completely doesn't care about strategic decisions.
My guess as to why this is the case is that such situations are genuinely rarely addressed in code review. Most productive PRs, from which an AI could learn, are designed around small well-defined features in the pre-agreed upon context. The context is never discussed in PRs because it's impractical (it would usually require too much of a change, so the developers don't even bring up the issue).
And this is where real large glacier-style deposits of tech debt live. It's the issues developers are afraid of mentioning because of the understanding that they will never be given authority and resources to deal with.
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.
which is why engineers want to be left alone to code, historically. Better to be left alone than dealing with insane bureaucracy. But even better than that is working with good bureaucracy. Just, once you know it's insane, there's not really anything that you can personally do about it, so you check out and try to hold onto a semblance of sanity in the realm you have control over, which is the code.
Small companies/startups don't have insane bureaucracy, and they're hiring.
In fact, it makes it harder.
I think the solution to using AI in coding is more testing, which unlocks even more AI.
> AI craze isn't going to produce the boon some people think it will.
What’s the boon you don’t think it will produce?
A classic example could be coal. The first steam engines used a ton of coal, but over time more efficient steam engines where created that used way less coal.
One might think that this caused the global coal usage to go down. But the opposite happened, as the overall cost of doing something with a steam engine went down.
Note, that the price of coal itself can remain fixed in this example. So Jevons principle is not (directly) about a resource changing in value.
If LLMs make codes cheaper to produce, then obviously more code will be produced. That's not an instance of Jevons paradox even though the article claims so.
You could say that LLMs means that we can create software with less of the resource that is human software engineers. So one might think that we'll need less software engineers in the future. If, on the other hand, we end up needing more software engineers, then that'll be an instance of Jevons paradox. But the article is not making that claim.
The People: Hey local government! The roads are so packed with cars they are useless. Fix it!
The Government: We hear you and just finished a huge road expansion project. The roads now have 2x the capacity! Enjoy the new fast roads!
The People: The roads are just as slow as before because they are packed with 2X as many cars now!
So, the paradox is that greatly increasing the capacity of the roads led to the roads being just as slow as before. Maybe even slower. This is because there previously were lots of potential uses of the roads that people did not enact because it would not have been worth the hassle. But, now with 2X the capacity, those uses become viable. So, more people find more uses of the roads up until it gets right back to the limit of everyone patience.
Apply this to coding and you can predict: Coding is much faster and easier now. So, why are all my coders still so busy?
Anyway, it's an specific observation about a single X, Y pair. It some times happens with other things, but anybody claiming it's a universal rule don't know what they are talking about.
We pay less per unit, but we pay more in total.
Why is this stated as a paradox? One simple cause is the given task being performed more than it was before because it is now cheaper (since it uses fewer resources).
"I got a Prius so now I am spending more money on gas" sounds ridiculous, but it would be an instance of this paradox.
So, increased efficiency can sometimes not lead to reduced latency, which goes against our natural thinking.
Sure.
But is it not also obvious that when usage of a resource becomes more efficient, the price of that ”usage” becomes cheaper?
So usage goes up obviously because efficiency increases.
It is called a paradox because some people naively think that increasing efficiency is a good way to decrease consumption.
Almost everything that is called a ”paradox” is this obvious.
An example of probably inelastic demand is the cost of diamonds which has fallen as synthetic diamonds enter the market. But people typically don’t buy more engagement rings than before.
With code it could be different. People might think that the amount of code that needs to be written is fixed, so the ability for a person to write code implies a reduced demand for people who write it.
In reality, bringing the cost down may unlock new use cases, so the number of actual coders might increase.
The bottleneck for making software applications better at being used by (non-software) businesses is making sure the software does all the software things that actually benefit the business. Save time. Make humans more productive. Reduce human error. Make the business more efficient. Increase profit margins.
All of those things are a bit difficult to predict and quantify. You start with ideas of what might help the business, you maybe design, prototype, trial. Ultimately you build or enhance software applications, and try to measure how well they're making the business better.
In all of this, making sure software is addressing the right problem in the right way, and ultimately making the business better - that's a hard problem! Regardless of how fast and easy it is to make software.
But yes, the speed can really help. You can prototype and trial and improve the feedback loop.
Based on what I’ve seen, prototyping has been always easy. You don’t even have to build software for the first iteration. For UI stuff you can use a wire-framing tool.
What has happened is that we abandoned the faster iteration methods (design think tank, quick demo and UX research,…) and we have full in on building the first idea that came in and fostering it on the users. That process is very slow and more often goes wrong.
Code changes. Not necessarily features, but also bug fixes, plain old maintenance, and even refactoring to improve testability.
With AI coding assistants, what in the past were considered junior dev tasks are now implemented with a quick prompt and an agent working in the background.
These junior dev tasks are now effortlessly delivered by coding assistants, with barely any human intervention. Backlogs are cleared faster than new items are added. And new items are added more and more because capacity to clear them is no longer an issue. The challenge is now keeping up with the volume of changes. I see this first-hand at my org.
> Those are pretty good bottlenecks for a company. I doubt an agent is fixing any of those. At least any time soon.
Just because you can think of other bottlenecks that doesn't mean that generating code was not a bottleneck, and is not the bottleneck today. The mere notion of a backlog demonstrates that it is a bottleneck.
They can't all be equally important bottlenecks; a bottleneck is by definition a singular component or sub-system most-limiting to the system's output.
What are we trying to output from our businesses? Code?
What is this magical context floating around every business that will unlock AI agents to produce ... what?
[Edit] I apologize for my tone. You're right, dealing with the speed of code generation is an unprecedented problem. I was making the argument that it's not the most important to the business and that rate of code change is very rarely the top concern. But that does not mean it's not the most important problem for someone. For the developers dealing with the system, it is.
Totally depends on what kind of product and codebase.
Last time I checked, the number of open issues in Claude Code repo has increased.
And I have seen tons of tickets that are open for years. Not because it's technically hard or anything. An intern can do that. Those tickets are not closed because nobody wants to deal with what comes after it.
If anything, genAI for coding is making engineers seek more engagement, that can't be a bad thing given the fracture between the business and product development.
What hermit wouldn't love meetings that simultaneously insist that you do more while taking away time to do it, all to avoid adjusting a pollyanna quarterly plan and budget!
> Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later?
is actually you (or some other reader) please quit/find a new job ASAP even if it means a pay cut. You don't want to deal with back issues, heart issues, weight issues, digestion issues, blood sugar issues - none of that. Please respect your body and your limited time with us. A coworker of mine had a stroke at thirty - that is a life changing event with, honestly, no real paths to full recovery.
Value your body, value your life. Your bosses see you as a piece of meat.
But when you factor in today's favorite business model of "make it shitty", perhaps this matters very little.
Both of these lectures misunderstand my point and how things work.
- “tech debt” is not some special problem…? You accumulate cruft and bad design decisions…you spend tokens to fix this. Is your point there is always a fundamental tension between spending tokens on new stuff and spending tokens on cleaning stuff?
> Honestly, this tells me that you basically understand nothing, not even chinchilla scaling laws and how RL works. Not only are you trying to brute force the problem, you're listing completely irrelevant factors to the problem at hand.
That’s a very interesting take because I would say the same thing! RL and scaling laws are not relevant to the performance and capabilities of coding agents? Thats something you don’t hear everyday
- chinchilla-like scaling laws are not ancient…people try to derive scaling laws for new paradigms all the time it is how researchers get their company/lab to invest in scaling up a new idea. No idea what you mean here. Maybe you think I meant “the literal constants from the chinchilla paper”? No I mean: scaling laws generally, and Chinchilla, due to the impact of that work, is used more generally. Regardless, scaling laws generally continue to hold, and in fact improve with architectural/data mix/training recipes.
> Reinforcement Learning is also a pretty bad example here, because there is no obvious way to encode a reward function to deal with something as ill defined as tech debt.
Well that’s a bit of a strong claim to make… I don’t agree with this at face value but even if I did, you don’t need to explicitly do RL on tech debt as a specific task.. you do RL to build better programming skills generally which then generalize to many coding tasks.
> You didn't even say avoid tech debt which would be actionable to some extent, just "systemic tech debt is now addressable at scale with LLMs".
Tech debt is strategic, why avoid it?
> you're implying that if LLMs were to generate tech debt, you can just keep scaling and produce more of it, solving the problem once and for all Futurama style with ever bigger ice cubes.
I’m saying you can take, successively over time larger and larger, and more complex codebases with thorny debt problems and resolve them by spending money on tokens.
You keep scaling and, just like we do today, decide when some tech debt austerity needs to take place. I’m saying “the guy that built our house of cards over 10 years and left” is no longer so devastating and expensive a problem as it was before
> I'm going to assume you were getting paid to build software that solved problems and created value for your customers and stakeholders.
That's a distinction without a difference. At least historically, I was "paid to build software that solved problems" and I was to do that by writing code. If I didn't write code, and enough of it, I'd be fired. Getting my flow state disrupted for no good reason was something I'd resist.
Also agile ceremonies are a drag, literally becoming the thing agile was originally supposed to be fighting against (not that agile is gospel, I've always disagreed with some of its practices). They're not a good reason. And I also mentioned an actual good reason. I should also note those meetings I was referring to positively were almost always with users, not tech people.
> Writing code has always been just one activity that's part of the job, and developers forget that and make statements like this! That's the parent poster's point.
I wasn't addressing the parent poster's point per se (and I noted that and why), just noting that a lot of the "collaborative" activities he cited were often not that collaborative, and the shade he was throwing at people who were unenthusiastic about participating in them was probably unwarranted and misguided.
tl;dr: OP needs to have more empathy. There are better ways to thread the needle of his observations than what was on display in his comment.
You do hit limits eventually (most people get to one smartphone and stop except for replacements) but the surprising paradox is when you don’t even see the possible demand (think: worldwide market for maybe six computers type things) - you have to think of something and then think of what would happen if it was (effectively) cheap as free.
Water in the USA might be an example, it went from something difficult and valuable and precious to we flush our toilets with drinking water - unthinkable wealth to parts of the world even today.
If a smartphone was fifty cents what new uses could be found? If the small shell script that replaces you is now $19 for anyone to develop, what happens?
Once the majority of the latent demand has been realized it will stabilize and start to go down.
In the current case of LLMs we’re seeing a Cambrian explosion of code that was quite doable before (demand was there) but there wasn’t the economics to dedicate a coder to it - now anyone with Claude can hack together something that works for them alone.
This is the part that’s no longer true. Everything else you said is spot on. But everything you mentioned — making sound decisions in the vast context of the business and enormously complex codebase, dealing with ambiguity and customer implications. None of this is inherently untouchable by AI
I wish the reality was more pleasant. It's not.
In any case, the point still stands: most companies absolutely can't code "faster than they can ship" and for that have huge backlogs of things they'd want to add or bugs to fix.
In some places, the ticket tracker works top-down: only the manager creates tickets, and the manager makes measurements about tickets closed, velocity, and so on to assess the productivity of their team.
I think the great divide on JIRA and JIRA-likes often comes down to which culture people have been exposed to.
You see it elsewhere as well. There's now a cottage industry (with visible members like Ed Zitron) who have made a career out of creating and selling anti-AI content. At first they were complaining that AI lies constantly. As AI got better, they shifted to other talking points.
> There's now a cottage industry (with visible members like Ed Zitron) who have made a career out of creating and selling anti-AI content
I can't believe that Ed Zitron, who I just looked up, has made a career out of creating and selling anti-AI content. He's 40. He cannot have been doing that for very long.
> At first they were complaining that AI lies constantly. As AI got better, they shifted to other talking points.
Calling the truth "complaining" seems more revealing of you than them. If the AI was lying constantly, they weren't "complaining". They were telling the truth. Once the AI stopped lying so much, they stopped saying that as keeping on saying it would no longer be true. But there are still other issues to talk about. That's...right? Isn't it?
I mean it really sounds like you're not on their side at all. It's their job to help you succeed, apparently. From what you've said already, you don't care about the project either. You're happy to waste time and money. It sounds like they're right not to trust you.
If I'm a manager of a team thats struggling and now also sabotaging additional resources, because they havent got the right warm and fuzzies, I'm going to be looking to have some difficult conversations. I'm also going to be very critical of anyone who floats a lack of "trust" as the blocker without some concrete evidence to justify it.
Whatever concerns they might have is not for the contractor to address. They are between them and their own management who deemed them unable to deliver sufficiently.
The aggregate for one person or for the world as a whole?
Tsunami?
The Claude Code repo features bug reports that are a mishmash of complains about prompt output, backend responses, documentation updates, browser extensions, etc.
Still, during the last week the repository reports ~2k closed issues vs ~1.3k new issues.
> People might think that the amount of code that needs to be written is fixed
Only people who never worked in a software company could believe that.
You don’t even have to unlock new use cases. Our backlogs are all full of old ideas.
Unfortunately these are many of the same people who make company-wide hiring decisions. They’re getting their sentiment from some guy 15 years younger who also never wrote any code, who heard a sound bite on a business podcast 6 months ago.
Resistance is also not the same as sabotage. My assumption is that everyone is acting in good faith from their own perspective. An immediate issue I see that the contractor was brought in because folks were looking at the calendar and not the tasks. Now the team is being pushed to carve out tasks. If shovel ready tasks are identified first, almost certainly, things go smoother. You're not context switching everyone. Its far less chaotic.
What you seem to not understand is empathy is going to move the team forward and deliver. Jumping to bad faith immediately is likely not the fastest way to a solution. If someone is struggling, its useful to understand why and address those problems. Its often not because they're bad.
I’ve been on all sides of this coin, and there is plenty of blame, misunderstanding, and bad ideas to go around.
Pushing a 90% solution through is a ‘win’ for the coder who is leaving, and hurts everyone on a continuing basis. It’s bad accounting, and lets the consultant look good for making the team perform worse (and look bad later).
And, IME, if that 90% solution needs a 100% rewrite after 40-80% burn in bugs and error chasing? What once was a bit behind is now way behind with staffing issues. Sunk costs don’t create extra budget.
Do It Right The First Time doesn’t always apply, only mostly always. Some people are insecure and territorial, yeah, but some know what their job is.
Entrenched engineers don’t want to you to alleviate or god forbid share the pain. Pain is good for employment security. And if the ship goes down, they’ll make sure they’re the last one to get fired, because there’s nothing the entrenched engineer fears more than having to job hunt.
I think a lot of HN truly believes that Software Developer is the only important role at their company. Software goes straight from the developer's brain, through his fingertips into the computer, and then on to the online store (run by nobody) for customers to buy. Engineering managers, program managers, product managers, marketers, MBAs, tech writers, QA, lawyers, process people, various admins and liaisons... they all exist to play pointless political games, have distracting meetings, and obstruct the One True Role. Design docs, planning, schedules, e-mails, JIRA, reviews, syncs, exec updates... all are useless parts of a scheme to torture the developer. It should just be "developers developing, and then money comes in from somewhere." This is an exaggeration, but you see these themes all over the comment section.
I doubt that. A lot of HN might have believed that some 10 years ago, perhaps, but most of those people have either matured or been driven away by the shift in the discourse.
I was one of the people who used to believe that, but the years of experience have taught me several important lessons that changed my mind. That change in attitude came both from my own failures and from having the rare privilege to work with people who were actually good at those other roles you listed.
> This is an exaggeration, but you see these themes all over the comment section.
And you'll keep seeing those comments, just like you'll keep seeing the comments about how developers are hypocritical divas. Those comments come from people's bad experiences.
Workplace political games are a thing. Unnecessary meetings and documents are a thing. Problematic, unprofessional developers are a thing.
It all begins with a product and a sale. That's how you go from zero to one.
Then if you're lucky enough to become an organization and start to have organisational problems you hire HR, accountants, lawyers, and managers.
But there will always be a dichotomy between core and auxilliary roles.
A coder and a salesman can create something out of nothing. We create the garden and those who come after tend to it.
Tech companies who grow large and old enough to forget that product and sales are the bedrock on which everything else stands decay and die.
Truth. I'm that person and didn't appreciate how rare I was until I became an EM and learned that most of my team would actively avoid conversations with the customer. Even though I have no way to quantify it, I'm sure it's benefitted my career.
Though I agree, most managers are BSing way too much, but the reality is that most Devs cannot navigate conversations like they think they can, and like you said, nor do they want to. And that is exactly what the managers do.
When I get good feedback it's like winning a prize and when it's bad it lets me see where we should be spending our time rather than were we perhaps thought we should.
This is a pointless statement though. The fact that writing code is a bottleneck, and a critical one, doesn't mean it's the only thing standing between us and fixing/implementing something.
It's like downplaying the time taken by international flights, because people can spend time passing through security.
The truth of the matter is that all software development processes is built around how slow code is written. Now code is ceasing to become a bottleneck and the current software dev process starts to emerge as inadequate.
If you say so. It's a honeymoon period for executives and a lot of them already got a lot of cold showers. It's just a very uncomfortable topic but it is already happening. Maybe not in your org but I am seeing it already.
I am not against the new reality even if it were to solidify (which it will not; productivity gains as sold are illusory and plateau VERY quickly; we're talking days -- and contrary to what many on HN believe, not all work is pitch decks and rapid prototypes).
I really like the acceleration and removal of dumb grunt work. I love it. But the current LLMs, even Codex and Opus, _are_ doing dumb stuff even on max effort still. People get hyped up and overshoot as they always do.
It must be said that I've used Opus for some pretty high-level and high-quality architectural work and it did very well -- but it took a lot of effort and steering, leaving me questioning whether I wouldn't have the done planning and scoping better and quicker.
Frontier LLMs do very well but people give them too much credit IMO.
You're asserting that it is critical. Why is code change speed critical?
What is your analogy getting it? It does not map to my argument evidently.
You're asserting it is slow code that has evolved our development process. Why? It used to be correctness and appropriateness. How is it suddenly speed?
Bottleneck for what?
One big misconception is that these models are trained to mimic humans and are limited by the quality of the human training data, and this is not true and also basically almost entirely the reason why you have so much bullishness and premature adoption of agentic coding tools.
Coding agents use human traces as a starting point. You technically don’t have to do this at all but that’s an academic point, you can’t do it practically (today). The early training stages with human traces (and also verified synthetic traces from your last model) get you to a point where RL is stable and efficient and push you the rest of the way. It’s synthetic data that really powers this and it’s rejection sampling; you generate a bunch of traces, figure out which ones pass the verification, and keep those as training examples.
So because
- we know how this works on a fundamental level and have for some time
- human training data is a bootstrap it’s not a limitation fundamentally
- you are absolutely right about your observations yet look at where you are today and look at say Claude sonnet 3.x. It’s an entire world away in like a year
- we have imperfect benchmarks all with various weaknesses yet all of them telling the same compelling story. Plus you have adoption numbers and walled garden data that is the proof in the pudding
The onus is on people who say “this is plateauing” or “this has some fundamental limitation that we will not get past fairly quickly”.
In the area I work I find them to be of very little value both then and now... I see no real difference. They help in marginal tasks. Eg. they catch typos, or they help new programmers to faster explore the existing codebase.
So far, I haven't used a single line of code generated by AI, even though I've seen thousands. Some of them worked to draw attention to a problem, but none solved it successfully. It was all pretty lame.
I see no reason to believe it's going to get better. Waving hands more forcefully isn't helping, there's no argument behind the promise of "it will get better". No reason to believe it will...
But, more importantly, the AI is applied on a level where really important things don't happen. It's automating boilerplate work. It doesn't make decisions about the important parts. Like, in the example above, the AI is not capable of choosing a better strategy: use pyproject.toml or write code to build Python packages? It's not the kind of decision it's called to make and nobody sensible would trust it to make such a decision because there isn't a clear right or wrong answer, only the future will prove one or the other to be the right call.
I find this statement highly suspect. AI coding agents nowadays can spot subtle object lifetime management issues and even dependency lifecycle incompatibilities, and here you are stating you are unable to use them to fix things? How strange.
Not to mention that coding agents excel at creating greenfield projects and migrating whole frameworks.
But if you feel you can't use them then I feel sorry for you.
> I see no reason to believe it's going to get better. Waving hands more forcefully isn't helping, there's no argument behind the promise of "it will get better".
That’s a real bummer to read that from someone who sounds like a professional, and not only a professional but someone thoughtful and smart. 30 years of brilliant work in RL, Bayesian stats, machine learning, measurement, and then trillions of dollars of funding and some of the best talent in the world, and your assertion is “I tried it on my codebase and I didn’t like it and that trumps literally entire fields of mathematics and statistics”. I mean, have you heard of Chinchilla scaling laws? Do you know how RL works? are you aware of benchmarks, their strengths and weaknesses? Are you following adoption numbers, accomplishments like new proofs of unsolved erdos problems?
> But, more importantly, the AI is applied on a level where really important things don't happen. It's automating boilerplate work.
Your experiences are your experiences, I don’t know what work you do or how it gets done, what languages you’re working with etc. but literally we’re at the point where the vast majority of code at major tech companies is fully AI written (not assisted).
> It's not the kind of decision it's called to make and nobody sensible would trust it to make such a decision because there isn't a clear right or wrong answer
What are you claiming is not fundamentally possible for an AI to do that a human can do here? People make judgement calls on ambiguous problems, taking into account vast amounts of context about the business, dev time, reliability, maintenance, etc; why do you think AI can’t do that?
The way AI is set up today, it's trying to replicate the (hopefully) good existing practices. Possibly faster. The real change comes from inventing better practices (something AI isn't capable of, at least not the kind of AI that's being sold to the programmers today).
AI is 100% capable fundamentally of making new processes. Look I mean it’s not like I think opus 4.7 is all you need, but how can you argue with the fact that adoption since 4.5 has been an inflection point? That’s kind of proof that reliability has reached a level that serious usage is possible. That’s over a period of months. When you zoom out further you see this is extremely predictable even a few years ago, despite the absolute hissy fits thrown on HN when CEOs began saying this.
Agentic coding is verifiable and this implies there are very few practical limits to what it can do. Combine that with insanely active research on tackling the remaining issues (hallucinations — which are not a fundamentally unsolvable problem at a practical level, context rot, continual learning etc)
I literally listed examples above... Code reviews weren't the norm until some time around 2010-ish. Then programmers realized that reviews help improve the code quality, and, eventually, this became so popular that today virtually everyone does it.
Anyways, I'll give an example from something that I've personally experienced / contributed to, which isn't as massive of a thing as code reviews, but is in the same general category.
Long ago, Git didn't have --force-with-lease option. Few people used `git rebase` command because of that (the only way this would work is if using it later with --force, which could destroy someone else's work). In the company I worked at the time, we extended Git to have what was later implemented as --force-with-lease. Our motivation was the need for linear history and some other stricter requirements on the repository history (s.a. every commit must compile, retroactive modifications in response to tests added later etc.)
This is an example of how a process, that until then was either prone to accidental loss of programmer's work or would result in poorly organized history was improved by inventing a new ability. This is also an example of something AI doesn't do, because, at its core, it's a program that tries to replicate the best existing tools and practices. It won't imagine a new Git feature because it has no idea what it could possibly be because its authors don't know that either.
> opus 4.7 is all you need, but how can you argue with the fact that adoption since 4.5 has been an inflection point?
What did it invent?
It's an inherent tension that every discipline has to wrestle with. The most experienced developers are in the best position to evaluate where LLMs are, but those who are the loudest about their own abilities generally aren't in this camp. Humility tends to come with experience, and arrogance tends to come with inexperience.
Fundamentally, LLM do not construct a consistent mental model of the codebase (this can be seen if you, uh, read LLM code,), and this is Bad for a lot of reasons. It's bad for long-term maintainability, it's bad for modelling this code accurately and it's behaviour as a system, it's bad for testing and verifying it, etc. Pretty much all of the tasks around program design require you to have that mental model.
You can absolutely get an LLM to show you a mental model of the code, but there is absolutely nothing that can 100% guarantee you that that's the thing it's using. Proof of this is to look at how they summarise documents, to look at how inaccurate a lot of documentation they generate is, and to look at how inaccurate a lot of their code summaries are. Those would be accurate if the LLM was forming a mental model while it worked. It's a program to statistically generate plausible text, the fact that we got the program to do more than that in the first place is very interesting and can imply a lot of things, but at the end of the day, whatever you ask for it, it will generate text. There is absolutely no guarantee around accuracy of that text and there effectively can never be.
You’re right that LLMs specifically have no guarantees about accuracy nor veracity of the text they generate but I posit that that’s the same with people, especially when filtered through the socialization process. The difference is in the kind of errors machines make compared to ones that humans make.
It’s frustrating we’re using anthropomorphic concepts like hallucinations when describing LLM behaviors when the fundamental units of computation and thus failures of computation are so different at every level.
> The difference is in the kind of errors machines make compared to ones that humans make.
There's another difference, and that is that other humans can learn and study that mental model (which is why "readable code" is a goal — the code is a physical manifestation of the model that you, the programmer, has to learn), and then the model can be tweaked and taught back to the original programmer, who can then think of that tweak in the future. Programming is inherently (in most cases) a collaborative art, because you're working with people to collectively develop a mental model and refine it, smoothing it down until (as Christopher Alexander said) there are no misfits between the model and the domain.
It can take a whole day to find 10 good lines to write.
So we've come full circle to code writing speed being a factor again? :)
In all seriousness, this just feels like a never-ending list of attempts to try to resist any notion that LLMs might accelerate software development, however small the increment. The original article was arguing that organizational and collaboration was the bottleneck and that taking a whole day to think about the code was not.
I could not have done this nearly as quickly. On the other hand, I gave it clear, precise instructions.
I've done a lot of "rebuild" / "second system" projects and the recurring theme is that the new version does less than the original. I don't think that's entirely down to the reality of second systems, I think that's in part because software grows over time but developers / managers rarely remove functionality. A full rebuild allows product owners (usually different from the ones of the original software) to consider whether something is actually needed.
The paradox would be:
* a TV used to be really expensive. So a home just had one
* over time TVs become half the price.
* now a home has 3 TVs, i.e paying 150% of what they initially payed.If you think that isn't a paradox because you can fairly easily explain why that is the case, you need to go and check what "paradox" means.
> No, we pay less for it. But there's much higher demand so overall use goes up.
This is economics 101, not a paradox.
To clarify how I read you: "If the price goes down, more people will want to buy, hence more units are sold"
The paradox is that _one_ person, or entity, pays more as the price goes down.
Reading 10x more code than before puts me straight into the zone. (In a language that I find interesting: Elixir)
My own process is improving so much that I had only one bug last week that was fixed immediately after the error tracker caught.
But yeah I feel more tired sooner. So it's oneto three hyper focus zones per day, just like before.
The difference is that I enter faster, and now I'm not afraid of leaving the task and resuming later, since I can just ask for a summary of what we did so far.
I'm using two different models from two different providers to cross check the work tho.
I'm very good with bad smells I guess, after years supervising less experienced developers since early days in my long career.
And requiring review of the result is not a "flow state". Flow states means continuous and uninterrupted focus while actively performing, LLMs block and return with new code or questions for minutes on end. That's the opposite of flow, it's the "let's take a break now, see you in a few minutes" for every interaction.
Are they devs or performance artists by now?
I think we’re talking past each other because your comment is like 99% interesting and insightful and also I agree with it completely but there is only one part of your claim that I have an issue with which is
> It won't imagine a new Git feature because it has no idea what it could possibly be because its authors don't know that either.
I left comments in other threads with a lot of detail but this is a fairly common misconception. It is true in a sort of practical sense today, and I have many experiences as you do with respect to this, but the gist is: this is a world of RL with verifiable rewards, you are not bounded by human ability at all and that is why we have the adoption, funding, and frothy excitement. It is not simply mimicking human coding. In early stages it will because human programming traces are used as kind of a bootstrap to get to an RL phase without any limitation on performance. This is a very well studied field and it just isn’t that much of a question of if and now it’s not even really a question of when.
> What did it invent?
This is a perpetual question with constantly moving goal posts so I’ve given up convincing anyone but by now it’s solving unsolved Erdos problems, not sure how convincing you find that (not opus though but that hardly matters now)
The point I’m trying to make is: we aren’t there yet but it’s a crazy idea to think that isn’t imminent given all of the measurement and observations we have.
Additionally my point on 4.5 being a turning point is adoption. You wouldn’t see adoption numbers if we were not accelerating rapidly from say 3.x performance along the scaling trend that we’ve known for years now
"I doubt the GP has gone back through their career and checked on each person who thought there were too many meetings have now all made the switched they're being accused of, though."
Anyway, I'm stopping this now as it's not a constructive conversation anymore. Let's agree to disagree.
How to do it? Focus on writing code.
New value: Producing high value software.
How to do it? Focus on writing specs for code / identifying needs.
I expect there are a lot of hypocrites in the mix, scared for their job. But this isn't a fundamentally hypocritical position - agents are changing the game for how software gets produced and the things that were important as recently as a year ago might reasonably be said to be irrelevant now. Ironically, we might yet see a great software engineer who has never written a program in their entire life. The odds are slim but it is possible now.
Old value: Returning value to shareholders.
How to do it? Treat your employees like family and don't be evil.
New value: Returning value to shareholders.
How to do it? Treat your employees like human resources and get away with what you can get away with.
Is this hypocritical? Most people would say yes, but in your framing it's not because we've backed up to the least specific articulation of an underlying principle. It's a species of the motte and bailey fallacy.
Agents may be changing the game for how software gets produced, but all it's really done is switch software developers from being managed to being managers. And software developers trying to square their historic value/principle that management tasks are useless, easy, and ceremonial (to borrow GP's word) tasks that should take a back seat to ~flow state coding~ with their new view that management is an integral, difficult, and requisite part of writing code reeks of hypocrisy.
I'm happy to defend that one too, for the reasons you outline. It is completely normal behaviour from a company, everyone understands it [0] and most managers I've worked with would be happy to talk about it openly. It isn't hypocritical. It'd be hypocritical to pretend that there was some sort of long-term commitment in an employment relation, but that isn't implied in your example.
Changing your behaviour when the situation changes isn't hypocrisy. That is just being aware of the conditions around you. Hypocrisy is pretending your behaviour is principles based, then clearly not following the principles. To show hypocrisy, you have to do two things (1) show people claimed to be following a principles and (2) show that they are not following it. In your scenario, you haven't identified a principle that people are being inconsistent with.
I note you threw in a "don't be evil", so maybe you're thinking of Google. Google is hypocritical, because it claimed to be acting on principles ("don't be evil") and then didn't follow them when it became inconvenient. But if it'd just been honest up front that it was a normal business and would act responsibly to maximise profit it could have undertaken exactly the same actions and not been hypocritical. It was the professing of principle in advance that made the hypocrisy, not the action. Claiming to "not be evil" is unusual for companies, because while they are immoral they usually only lie when it is detectable that it is to their benefit and they're usually just cynical, not hypocritical.
[0] "should" understand it, I suppose. One born every minute.
You can't be a dick on this platform without fancy prose I guess.
Looking at a slice of most folks' workday and calling it their whole job is in my opinion, incorrect.
Uh yes it does?? What are you talking about.
I don't think switching one's passion on a dime is a valid escape hatch from hypocrisy.
You're wrong. It's a virtue.
You don't know buzzword A, B, C? Heh, he must be incompetent and know nothing.
The buzzwords mean nothing, really. The math is the same for a stupid or a smart model, because the model is trying to mimic properties of the training dataset.
You can give me the ultimate model architecture that will beat every model in existence and I can still figure out a way to make it perform worse than what's available today, but you're not even doing that, you're just drumming up some old news.
If someone "threatened" me with tech advancements I would be more worried about things like an imminent massive drop in token costs for bigger context windows or other game changers like continual learning where the model internalizes your code base into its weights rather than just keeping it in its context.
> You can give me the ultimate model architecture that will beat every model in existence and I can still figure out a way to make it perform worse than what's available today, but you're not even doing that, you're just drumming up some old news.
Sorry I don’t understand what you’re saying here — what is the old news? You can break new models — yes. What’s the point you are trying to make here?
> If someone "threatened" me with tech advancements I would be more worried about things like an imminent massive drop in token costs for bigger context windows or other game changers like continual learning where the model internalizes your code base into its weights rather than just keeping it in its context.
I also don’t really know the point you’re trying to make here — like token cost drops seem like a good thing? Bigger context window too? Are we saying the same thing here?
Although at least it has some cross-cultural references. Why is naming so hard.
A "human" is just a "featherless biped", after all?
I think the Goomba Fallacy captures something helpful to me- it's helpful to know the origin of a straw man if you want to un-stuff one.
First, it becomes possible for people who have a double standard to hide behind this. One can try to track an individual's stance, but a lot of internet etiquette seems to be based on the idea of not looking up a person's history to see if they are being contradictory. (And while being hypocritical doesn't necessarily invalidate an argument, it can help to indicate when someone is arguing it bad faith and it is a waste of time as someone will simply use different axioms to reach otherwise contradictory conclusions when they favor each.)
Second, I think there is the ability to call out a group as being hypocritical, even when there are two sub groups. That one group supports A generally and another group supports B generally (and assuming that A + B is hypocritical), but they stop supporting it when it would bring them into conflict indicates a level of acceptance by the change in behavior. Each individual is too hard to measure this (maybe they are tired today, or distracted, or didn't even see it), but as a group, we can still measure the overall direction.
So if a website ends up being very vocally in support of two contradictory positions, I think there is still a valid argument to be made about contradicting opinions, and the goomba fallacy is itself a fallacy.
Edit: Removed example, might be too distracting to bring up an otherwise off topic issue as an example.
But if A and B are opposed, then there is a question of why a strong position on A can be allowed with a weak position on B, if the reason for the strong position on A would also indicate a strong position against B.
The underlying argument being implied (but rarely ever directly stated) is to question if your reason for the strong position on A is really the reason you state, or if that is just the reason that sounds good but not the real reason for your belief.
In effect, that you don't apply the stated reason to B despite it fitting is the counter argument to why it doesn't actually support A.
If there is an inconsistency in arguments being applied, any formal discussion falls apart and people effectively take up positions simply because they like them, contradictions irrelevant. This generally isn't a good outcome for public discourse.
Gave me a good laugh, thank you. :)
Its because it comes from the same political faction. In general people are open about A when A seems palatable, and openly B when B seems palatable, but they almost never admit to do that when its obviously wrong to do so.
That is the rational part of the fallacy, even if these are different sets of people you can still tell they are biased since they never appear in the threads where its obvious they are in the wrong.
For example, lets say in a thread where a white cop shoots a black guy you find a lot of republicans say "this is just statistics, nothing to see here". Then in another thread where a black cop shoots a white guy republicans pour in and argue this must be racism and we should investigate! Maybe it isn't the same set of people, but its still a strong sign of problematic bias that they only choose to speak up in those particular threads and not the others.
Every political side everywhere does this, and that is why people started calling that out.
I think it's very silly to make the argument that "groupwise hypocrisy" is not a fallacy in such a conversation. In politics, the reality is that people have to form coalitions with people with whom they don't agree on everything, and non-political groupings are even more non-sensical, often holding people responsible for the opinions of other people who happen to share things like inborn characteristics. It's especially ridiculous to explain this with this idea that people are engaging in some kind of elaborate coordination to argue with you on the internet. Yes, some people, and indeed political parties, engage in that kind of behavior, and if you think you're arguing with something like a botnet, there are larger considerations to make about what you gain as an individual by trying to engage with such a machine at all. If I believe I'm arguing about the merits of an idea with an actual person, and I find myself reaching for something like "your group is collectively hypocritical on this issue" to make my argument, this is cause to reflect on whether I actually have any real arguments for my position, as that one is... well, essentially meaningless
I think you're trying to invoke what's commonly called a "motte-and-bailey" argument, where people argue for a maximally-defensible position when faced with serious criticism, but act as though they're proving a much less defensible version of their argument, often including a nebula of related ideas, in other contexts. This is something individuals and coordinated factions absolutely do, but again doesn't really support treating any grouping you want to draw of some kind of collective hypocrisy. Even assuming we care about hypocrisy, it seems like this kind of reasoning about nebulous groups that don't explicitly coordinate would allow making that argument about any position in any context, depending on how you draw the boundaries of the group that day. It's well-understood that you can go on the internet and find someone who believes just about any crazy thing you can think of, or find someone who makes the argument for any position poorly.
But nah, clearly they're all goombas.
it concerns you because you have a good authority over your spoken language, and like most people with those skills I presume the language flows easily from you.
that ability isn't guaranteed, for a lot of people expression is tough, and those people felt equally alienated when confronted with an essay of word salad about why their opinion is wrong.
An LLM is a tool. In the 90s I would read columns and editorials about the disgusting faux pas of replying to a wedding invitation via such a cheap trendy medium like internet e-mail , now you receive death certificates that way.
It's not all bad, simpletons can use LLMs to have the critiquing essays turned into 5 word ELI5 statements that they can become enraged over once all the nuance is stripped. That's fun!