It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching about about the vital importance of collaborative activities and the apparent inconsequence of code and coding, the moment a machine was able to do the latter faster than them. I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.
Are you referring to the author specifically? Or a specific hypocritical person you know? If you're making a general statement about groups of online people you might be falling for the group attribution error[1], where the characteristics of an individual are assumed to be reflective of the whole group.
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.
This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better).
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.
Yes! So much of professional software development is about assisting the nominal job of management—planning and budgeting—rather than users or even business fundamentals.
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.
Not a false dichotomy. I agree with OP and I can say for certain that if you are one of the few developers that is "fond of meetings with customers" you are not the the type of person OP is talking about, and you are more rare than you think.
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 :)
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.
Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable.
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.
Ceremonies and tickets aren't especially effective for actual collaboration. They're primarily tools for making work legible and controllable to management.
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.
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.
The bitching was about meetings and ceremonies that took away the little time left to spend time asking more features to be implemented, or revisited before it could get completed.
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.
The people I know like this are people I consider to be "advanced juniors". They are held back by their inability to work with other parts of the business and understand customer needs. In order to be successful they need to be spoon fed requirements. What I've seen from the limited sample in my orbit is that they've actually doubled down on AI and are creating little private worlds of agents and further isolating themselves from the business, not talking about how great collaboration and such are.
Just because I hate those ' team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state"' - doesn't mean I don't understand how important they were and are. I moaned them before, and will continue to - but they were always important. I have learned the hard way more than once what happens when you sit at a keyboard and write code (one time I lost my job because the code I was writing was so far out from what the company needed, the next I realized what was happening in time to leave first - only after I was gone did they realize that what I was doing really was important and they made me a good offer to come back)
/s Oh noooo, it's like they're turning into managers... Now that machine can do their job better than them they've become as unimportant as you always thought they were, always pretending to be banging keyboard where it used less brain cycles than highly important work like posturing in a meeting did. Anyone can bang a keyboard even a machine can do that now, it can surely never replace important work of you having to 10 meetings. Lets replace all of them with machines and us meeting lovers can run the company with the machine produced work that we never have hope of understanding.
I'm not in the group you described so I don't want to speak for them, but I can empathize because there are some things that are meaningfully different with AI:
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".
It's 100% denial/ego. I've been a contractor longer than I'd like and it's the exact same response I see when I join a new team. The team complains they have too much work and can't get anything done, so their manager pulls me in. Suddenly, they don't want to give anything up. I'm actually in the middle of this right now. The team "is swamped" yet somehow, they are able to argue that almost everything I can handle is best handled by them and they don't need help. Fine by me, I'll sit around and get paid. But it smells exactly the same. They don't want to admit that A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload.
> A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload.
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.
Well who are you? Why should they trust you to actually complete a task and not dump unfinished work on them when your contract is up?
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?
There's nothing hypocritical about preferring the part of the job that isn't the bottleneck and wishing one could spend more time on enjoyable things. Nor is code being called "inconsequential" simply because it can be done (more) easily.
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.
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.
But it is written there, and GP was quite specific:
>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
I posit that getting into a coding flow state isn't just about producing code. It morphs and develops the problem space in the engineer's head. It helps them realize where the spec is lacking. It familiarizes them with the capabilities of the codebase so they can speak confidently about what future changes will entail.
The activity that needed and still needs to be protected is problem solving:
- 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".
That's just scarcity based economics doing its thing.
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.
Just because concurrent design, QA, research etc push out the Gantt chart doesn't mean your meeting isn't useless.
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.
You’re describing a multitude of different people with a variety of viewpoints. It’s also smart to change your mind when the environment changes; code being easy to write is a decisive shift.
Two things can be true at the same time. Yes, those meetings are horrible, and plenty of times they're useless and can be summarised as "why wasn't this an email/slack message", but also plenty of those same meetings can equally be extremely important.
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.
Yea, when you have multiple people doing anything, communication has to happen. It's not optional. As soon as your company hires developer #2, you need to communicate. As the team sizes get larger, 1:1 in-person conversations become less important and you need E-mail. As the team sizes get even larger and non-developer stakeholders become more numerous, meetings creep in. These things are not developer-torture devices. They are happening because your company decided that the product needs to be built by more than one person.
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.
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
My sense is that it's the opposite. The people who complain about meetings, managers, and methodologies also complain about agentic coding. The people who are excited about frameworks, methodologies, and project management tooling are excited about agentic coding.
Is it hypocrisy or learning? A more charitable take - it wasn't too many years ago that I also decried the need for all the collaboration. But as I advanced in my career, that worldview just didn't hold up. In this case, maybe the introduction of agentic coding has accelerated that learning because now 'regular' engineers are forced to take on coordination roles.
[With that said, the specific implementations of such collaboration are often still very painful and counterproductive...]
> I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.
I don't think there is any hypocrisy. The error in the analysis is assuming both conflicting opinions are held by the same person. They aren't.
That's an oppinion for sure, and a very shallow, general oppinion. Some people like solving problems, sometimes via code, while others tend to hide behind the 'Collaboration' banner, to help their own career progression. Both are legitimate tracks. To dismiss one, is to make the other appear 'non-Good'. But, perhaps data can be furnished as part of this post to support either as 'better'.
They sound like very important people no matter what the circumstances are, haha.
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.
There are 2 bands: you let people earn a living or you let investors/executives become richer every year to the detriment of workers. I don’t care about the medium, Im not with the big fishes
It's certainly the case that the collaborative ceremony can be mismanaged, and that is frustrating when you need time to implement. I don't expect that complaint to go away, those who are using AI heavily will replace it with not having enough time for prompting.
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.
I feel attacked. I still dislike most team meetings, agile ceremonies, etc. Slack and emails give me anxiety. A 30 min meeting will disrupt me for 90 minutes. But, yea, the code was never the bottleneck. Except maybe when I worked at a startup. All of the above are true.
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.
It's an astute observation but overstated. There are just as many programmers who view their activity as too sacred to consider using an LLM, even for relatively easy, predictable, or disposable work.
Yes this exactly, it's getting ridiculous at this point.
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.
Looks like this comment is touching a nerve. This community is progressing from "AI can't write code", to "Well, AI can write code but it's not really about the code". I wonder where the goalposts will be moved next?
Both your error and the OP's error is in imagining that the same people are saying both things. The "community" fallacy, which has been around for about 10 years now, that pretends that people with something in common (e.g. "uses HN") are somehow a community that thinks identically is completely wrong.
The community portion that unironically think AI is good enough now, are mostly managers and non/semi-technical people, and engineers who do not engage in critical or complex problems. HN has always been too much of the velocity-alignment-synergy class of professional talkers; it's just so much more obvious now that they feel emboldened in false confidence.
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.
Collaborative activities and process being important is NOT mutually exclusive with many meetings being useless, agile ceremonies time wasting uselessness and design review being used as a place to pontificate about crap.
NONE of the activities you mentioned are activities that lead to what article talks about - well designed spec.
But the flow state wasn't just about typing code. The flow state was about understanding the problem, about loading it into your head so that you could "walk around in it" mentally, so that you could figure out that what really needed to happen was that module X needed to add a getter to value foo, that module Y needed to get foo and make a change based on the value, and that the key to making this all work was to add a way for Y to access X that fit within the existing architecture. That took focus, far more than implementing the pieces did.
Just look at what they write. There is a correlation between the Agentic Multitasker and the type of person who wanted results and didn’t care about the coding in itself. That’s what they themselves keep writing.
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.
I would say in general the amount of persons who pivot like that is low.
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.
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.
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.
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.
I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company's I have worked at in the long-term.
> The inability for the business to define a focused, productive roadmap has always been the problem in software engineering.
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.
Any competent engineer should understand that engineering is just the assembly line side of product development. Deciding when to release which feature, bug fixes, etc. and the development/management of the product in general has always been the real challenge, and a lot of the strategy involved in doing this relies on feedback loops that AI cannot speed up. Though at the same time I do feel like leaders on the business side often scapegoat engineer's speed as an excuse instead of taking responsibility for poor decisions on their end.
I get what youre trying to say but this is actually a bad picture to defend. product and engineering should go hand in hand, with one side informing the other. Engineers sctually giving a shit about a product will tell product possibilities they havent even considered, product people caring about engineering will not propose utterly stupid things. and I for one can spot when a product is well designed but poorly made, as well as when a product is perfectly crafted yet useless. the sweetspot is both. and even with the speed multiplier of AI, having a proud in the craft and being actually good in it as an engineer makes a night and day difference for the final result.
> [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
> I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical.
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.
yes, most places I have worked were hobbled by the organizations being completely idiotic.
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.
It’s part of the problem but AI also can crush this on pure lines of code and functionality alone. It can put out 100,000 lines of somewhat decent code in a day. That usually takes months or years of manual coding for a team.
For business, software applications are tools that facilitate "the thing" that generates money. (We in the software world think that _thing_ is software and software _features_, but outside that world, there's usually a different _thing_.)
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.
> 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.
> 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.
Should the paradox not be that we PAY more for it?
Or, if some process is made more effective, i.e. takes shorter time, we spend more time in that process.
What kind of projects are people working on, where understanding what features the management wants is the only difficult part and the rest can just be "typed out" (or, today, offloaded to an LLM)? If that's what you do, then I'm not surprised so many people on HN think LLMs can replace them.
Any discussion related to this topic always seems to assume everyone uses code the same way and for the same function, and then forces the rest of the world through that lens.
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.
Uno reverse. What kind of limited project experience would lead anyone to think that there isn't an enormous continuum between code difficulty and organizational problems in the space of software development?
This is like 80% of CRUD apps. Sometimes they have a few interesting problems but not like the upper 20%. Most of them are hot garbage in terms of code quality because of the offshoring and layoff cycles.
I think the argument here misses critical nuance; there is a difference between code used to implement a product and when code _is_ the product.
It goes without saying that agents have little to no product sense in any discipline. If you're building a game or an app or a business, your creative input still matters heavily! And the same is true for code; if the software is your product, then absolutely the context missed by skipping the writing process will degrade your output.
That doesn't mean that writing code wasn't a bottleneck even for creating well structured software projects. Being able to try multiple approaches (which would have previously been prohibitively expensive) can in many instances provide something a room of bickering humans never would have reached.
I think what I'm trying to get at is that there's a lot of code out there that really just needs to work. It doesn't need to scale to millions of users, it doesn't need to be abstract-able and useful to use cases we don't even know about yet, just needs to get an idea off the ground. That code is not the product. In such a case writing the code very much is a bottleneck.
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.
On desktop, it's fixed to the left of the story, pulsing along the entire time you're trying to read. If you are like me, it will annoy you. I had to switch to reader mode.
I think he's going for a metaphor about groups versus individuals. There are other gray dots around the red dot. Software is a group effort, but made of individuals. Something, Something.
One of the bottlenecks has always been the code. That code has been stolen and is being laundered while companies rely on mediocre engineers who have never written anything of value to promote the burglary tools and call the process "writing software".
It is the same as putting an Einstein paper on a photocopier and call the process "writing a paper".
I agree with the point of the article though: code generation does not really work, the results are bloated and often wrong and people already had more features that they could absorb in 2020.
The solution to this mess is to have 18 year olds boycott studying computer science altogether, since the industry (and mediocre fellow "engineers") will treat them like human garbage.
Personal anecdote. When I started as a wide-eyed university co-op, I was surrounded by a team of aging mainframe developers who had been coding since the 1960s. Their backgrounds ranged from working their way up from the mailroom to astrophysics to masters degrees in computer science. What struck me was how the entire team treated coding as a form of art. Of course, it had to be functionally correct and maintainable, but you could glance at a snippet of hyper-efficient PL/1 and instantly tell that 'Larry' or 'Trudy' wrote that routine - each programmer had a unique style, along with just the right amount of comments to make you laugh and guide you through difficult bits.
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.
I think the solution is to fix society so that we value quality over quantity, self betterment over getting rich, and making society better for every one rather than worshipping billionaires.
Doesn't add up. I used to spend more than half my time coding, as did others. Besides the obvious cost, that coding took wall-time which meant talks had to wait. Sure a poor collaborator will jam things up a ton, but a team of at least ok collaborators used to be bottlenecked on code.
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 problem with this is that everybody thinks they have better ideas than they do. And engineers are probably the worst offenders in that they're smart enough to make a case that deludes themselves.
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.
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
Sometimes code is definitely the bottleneck. For example some organizations have a very bureaucratic process guarding which projects get access to a development team and when. That's not needed if implementation is now faster/cheaper.
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 think he is saying, I hope he is saying, that software has never been writing software, it has been communications with people over what the software should be, needs to be, and the entire point all along has been to achieve better collaboration with people, and implied: to achieve their collective goal. He spends a good amount of time on how slow writing software has been in the past, and that allowed the industry to over focus on the software writing. While it has been pointed out a number of times by milestone books our industry embraced that it is the communications aspect of why and what we write that is the most important. Finally now that is being forced upon us because writing code is now automated, and all that is left is the specification and the communications with humans over what and why.
The author argues that writing code cannot be a bottleneck because work always fills up the allotted time. Developer teams should instead focus on doing less and writing better specifications.
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.
I think the point they're trying to make is that context known by humans and the requirements they agree on, is 'the' bottleneck, rather than implementation
Absolutely matching the gut feel I've had lately. We've always been pretty good at producing bad code very fast. All of the other stuff - dependency management, learning what's valuable, ownership & boundaries, context switching costs, etc... have always been the bottlenecks and it's just more obvious now.
So managers are overwhelmed because the code is now happening a lot faster? It sounds like the immediate bottleneck really was the code, at least frequently. Now it seems the bottleneck is managerial.
> Agents that consume context need agents that produce it. Once that loop is running, the organization has a written substrate it would never have produced on its own.
I'm not sure a business is helped by documentation that distilled from (hopefully present) PR descriptions and comments in JIRA, by agents. Or wherever this context is supposed to be reverse-engineered from.
The company website linked in the article is broken https://www.dottxt.ai/ on (mobile and desktop) Safari. Looks like your cert doesn’t cover the www subdomain.
The bottleneck has always been the human element. I too used to be one of those up-my-own-ass engineers who thought the most important part of my work was the machine, and it wasn’t until I began actually listening to others and their problems that I realized my function was far more than mere technology scaffolding.
That said, I’m also increasingly aware that puts me in a minority group. I got to see this first hand in a recent org where their codebase and product design hadn’t meaningfully evolved in nearly thirty years. NAT was a “game changer” to them - and one they refused to implement without tons of extraneous testing they would deliberately undermine, stall, and sabotage so they didn’t have to modernize their code accordingly. It was easier for the developers and stakeholders to preserve their own status quo rather than entertain alternatives, to the point of open hostility (name calling, insults, screaming, and a few threats) to anyone suggesting otherwise.
The human element has always been, and always will be the bottleneck. Stakeholders who don’t contribute updated or accurate datasets to automation systems, or who hold back development to preserve personal status and power, or who otherwise gum up the works on purpose to game their own careers.
That’s not to make the argument of “replace all humans with machines”, mind you. Just stating that an organization that incentivizes bad behavior will be slowed down versus ones that incentivize collaborative outcomes, and AI is just going to turbocharge that by removing the friction associated with code creation and shifting that elsewhere.
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.
I was already looking, but they ultimately made the decision for me in January with a RIF.
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.
the bottleneck was never the software, that is the ship we ride,
people, are part of a team focused on a goal, they work together because they believe in that the ship is worth riding on and will reach its destination,
the ship should carry food people want,
team decides what food will be consumed,
captain tries first the food,
if food is good and people want it, people buy more
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.
I can see the division here already, and the cogs are afraid. As a dev of 25+ years, currently working for a small company who came from a global company, I see both sides. I'm very excited about AI and love to see my projects come to life so much faster. I still love the craft of code, but its always been about the product for me.
The paper hits the nail right on the head, but it misses the mark on the next constraint: how to decide what to build.
In the old days when writing code took up a lot of resources, the constraint was self-correcting since being off in your implementation was obvious enough that the error could be easily seen after three months of work on the wrong feature. Today, you could spend five wrong efforts in the same amount of time that it used to take you to implement one wrong effort.
Or startups where coding was always a bottleneck because it was very expensive to hire swes, unlike big corps which would often throw swes at a problem.
If thats true, I am sure some C-suite manager knows this already. Assuming management knows what they do, after all, they're getting payed for this. The time where engineer are trying to educate people above them should be over. Management gets payed for the big decisions. If they tank the company, so be it. I no longer care.
> What may save us it that agents are unreasonably good at reading exhaustively. An agent will read every PR comment, every closed issue, every commit message, every stale design doc ...
> 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.
It also bakes in the LLM quality at the time the documentation was generated, into the documentation. It potentially worsens the performance of future LLMs if they ingest the documentation produced by older LLMs. It’s not clear why documentation wouldn’t instead be generated on demand, using the newest SOTA LLM.
It seems like so many developers know this, yet here we are. SV pushing this AI slop economy. More code! Faster! Less testing! Less understanding! It's what we NEED!
It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching about about the vital importance of collaborative activities and the apparent inconsequence of code and coding, the moment a machine was able to do the latter faster than them. I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.
Are you referring to the author specifically? Or a specific hypocritical person you know? If you're making a general statement about groups of online people you might be falling for the group attribution error[1], where the characteristics of an individual are assumed to be reflective of the whole group.
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.
[1] https://en.wikipedia.org/wiki/Group_attribution_error
Or just goomba fallacy
18 replies →
> 2. It's annoying and disruptive to be interrupted when doing work that requires deep focus.
Steering a LLM also requires deep focus. Unless you want to end up on accidentally quadratic or have a CVE named after your project.
5 replies →
This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better).
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.
Yes! So much of professional software development is about assisting the nominal job of management—planning and budgeting—rather than users or even business fundamentals.
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
Well said.
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.
Not a false dichotomy. I agree with OP and I can say for certain that if you are one of the few developers that is "fond of meetings with customers" you are not the the type of person OP is talking about, and you are more rare than you think.
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 :)
5 replies →
> nakedly hypocritical
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.
Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable.
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.
7 replies →
Ceremonies and tickets aren't especially effective for actual collaboration. They're primarily tools for making work legible and controllable to management.
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.
This seems to confuse cause and effect.
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.
The bitching was about meetings and ceremonies that took away the little time left to spend time asking more features to be implemented, or revisited before it could get completed.
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.
> No developer was ever unhappy to communicate
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.
The people I know like this are people I consider to be "advanced juniors". They are held back by their inability to work with other parts of the business and understand customer needs. In order to be successful they need to be spoon fed requirements. What I've seen from the limited sample in my orbit is that they've actually doubled down on AI and are creating little private worlds of agents and further isolating themselves from the business, not talking about how great collaboration and such are.
Are my standards too high to expect juniors to also be able to work with other parts of the business and ask for additional requirements if needed?
1 reply →
Just because I hate those ' team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state"' - doesn't mean I don't understand how important they were and are. I moaned them before, and will continue to - but they were always important. I have learned the hard way more than once what happens when you sit at a keyboard and write code (one time I lost my job because the code I was writing was so far out from what the company needed, the next I realized what was happening in time to leave first - only after I was gone did they realize that what I was doing really was important and they made me a good offer to come back)
/s Oh noooo, it's like they're turning into managers... Now that machine can do their job better than them they've become as unimportant as you always thought they were, always pretending to be banging keyboard where it used less brain cycles than highly important work like posturing in a meeting did. Anyone can bang a keyboard even a machine can do that now, it can surely never replace important work of you having to 10 meetings. Lets replace all of them with machines and us meeting lovers can run the company with the machine produced work that we never have hope of understanding.
I agree with this sentiment https://news.ycombinator.com/item?id=48033534
I'm not in the group you described so I don't want to speak for them, but I can empathize because there are some things that are meaningfully different with AI:
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".
It's 100% denial/ego. I've been a contractor longer than I'd like and it's the exact same response I see when I join a new team. The team complains they have too much work and can't get anything done, so their manager pulls me in. Suddenly, they don't want to give anything up. I'm actually in the middle of this right now. The team "is swamped" yet somehow, they are able to argue that almost everything I can handle is best handled by them and they don't need help. Fine by me, I'll sit around and get paid. But it smells exactly the same. They don't want to admit that A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload.
> A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload.
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.
3 replies →
Well who are you? Why should they trust you to actually complete a task and not dump unfinished work on them when your contract is up?
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?
3 replies →
There's nothing hypocritical about preferring the part of the job that isn't the bottleneck and wishing one could spend more time on enjoyable things. Nor is code being called "inconsequential" simply because it can be done (more) easily.
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.
I'm not going to comment on the likely "Goomba fallacy" at work in your comment, but I just want to note:
> 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.
> the same kind of engineer
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!
https://hn.algolia.com/ - search for "actual work" This has long been a topic on HN.
But it is written there, and GP was quite specific:
>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.
3 replies →
I posit that getting into a coding flow state isn't just about producing code. It morphs and develops the problem space in the engineer's head. It helps them realize where the spec is lacking. It familiarizes them with the capabilities of the codebase so they can speak confidently about what future changes will entail.
The activity that needed and still needs to be protected is problem solving:
- 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".
That's just scarcity based economics doing its thing.
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.
Just because concurrent design, QA, research etc push out the Gantt chart doesn't mean your meeting isn't useless.
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.
You’re describing a multitude of different people with a variety of viewpoints. It’s also smart to change your mind when the environment changes; code being easy to write is a decisive shift.
Code may be easy to write once you know what the code needs to do.
Two things can be true at the same time. Yes, those meetings are horrible, and plenty of times they're useless and can be summarised as "why wasn't this an email/slack message", but also plenty of those same meetings can equally be extremely important.
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.
Yea, when you have multiple people doing anything, communication has to happen. It's not optional. As soon as your company hires developer #2, you need to communicate. As the team sizes get larger, 1:1 in-person conversations become less important and you need E-mail. As the team sizes get even larger and non-developer stakeholders become more numerous, meetings creep in. These things are not developer-torture devices. They are happening because your company decided that the product needs to be built by more than one person.
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.
Just because you use LLMs doesn't mean you don't need the "flow". Reading code SUCKS, getting into the flow is harder than ever.
Unless you sign off on a Looks Good to Me PR and go loiter by the kombucha machine. Then you have other problems.
The amount of cognitive dissonance I'm seeing on HN right now is concerning.
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
"both these beliefs" and you label one a Belief and the other a Fact.
THIS COMMENT IS GOLD.
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
Or the person just likes to lock into flow states at the point of maximum leverage. Previously that was coding. Now it’s commanding agents.
I've got nothing to add to the discussion but want to take a moment to appreciate your ability to construct long sentences. It flows beautifully.
My sense is that it's the opposite. The people who complain about meetings, managers, and methodologies also complain about agentic coding. The people who are excited about frameworks, methodologies, and project management tooling are excited about agentic coding.
Meanwhile people who bitch and moan about “other engineers” all the time haven’t changed at all. How refreshing.
Is it hypocrisy or learning? A more charitable take - it wasn't too many years ago that I also decried the need for all the collaboration. But as I advanced in my career, that worldview just didn't hold up. In this case, maybe the introduction of agentic coding has accelerated that learning because now 'regular' engineers are forced to take on coordination roles.
[With that said, the specific implementations of such collaboration are often still very painful and counterproductive...]
> I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.
I don't think there is any hypocrisy. The error in the analysis is assuming both conflicting opinions are held by the same person. They aren't.
That's an oppinion for sure, and a very shallow, general oppinion. Some people like solving problems, sometimes via code, while others tend to hide behind the 'Collaboration' banner, to help their own career progression. Both are legitimate tracks. To dismiss one, is to make the other appear 'non-Good'. But, perhaps data can be furnished as part of this post to support either as 'better'.
They sound like very important people no matter what the circumstances are, haha.
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.
There are 2 bands: you let people earn a living or you let investors/executives become richer every year to the detriment of workers. I don’t care about the medium, Im not with the big fishes
It's certainly the case that the collaborative ceremony can be mismanaged, and that is frustrating when you need time to implement. I don't expect that complaint to go away, those who are using AI heavily will replace it with not having enough time for prompting.
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.
I've had seniors tell me my entire career that writing code was the easiest part of their jobs.
True
I think there’s some kernel of validity in this comment, but the unnecessarily aggressive tone loses it. This just comes off as bitter.
I feel attacked. I still dislike most team meetings, agile ceremonies, etc. Slack and emails give me anxiety. A 30 min meeting will disrupt me for 90 minutes. But, yea, the code was never the bottleneck. Except maybe when I worked at a startup. All of the above are true.
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.
Um… how do you get those requirements if slack / email give you anxiety ? And meetings are disruptive ?
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?
Isn't solving problems, instead of blindly implementing a high-level description of the solution, your job as a developer?
1 reply →
They are still anti-social. But they see the “social” as a way to feed the AI better, to make better code.
The focus is still the code.
It's an astute observation but overstated. There are just as many programmers who view their activity as too sacred to consider using an LLM, even for relatively easy, predictable, or disposable work.
Generally, groups of people aren't homogenous.
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".)
Yes this exactly, it's getting ridiculous at this point.
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.
Comments like these are why I still come to HN. Absolute kino.
Looks like this comment is touching a nerve. This community is progressing from "AI can't write code", to "Well, AI can write code but it's not really about the code". I wonder where the goalposts will be moved next?
Both your error and the OP's error is in imagining that the same people are saying both things. The "community" fallacy, which has been around for about 10 years now, that pretends that people with something in common (e.g. "uses HN") are somehow a community that thinks identically is completely wrong.
1 reply →
The community portion that unironically think AI is good enough now, are mostly managers and non/semi-technical people, and engineers who do not engage in critical or complex problems. HN has always been too much of the velocity-alignment-synergy class of professional talkers; it's just so much more obvious now that they feel emboldened in false confidence.
7 replies →
This community hasn't agreed on either of those things, just like it never agreed on good coding practices.
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.
LLMs have been getting a lot better at coding.
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.
Is it even a problem that so called goal posts are moved?
That's life.
Life changes and us along with it.
"Who Moved My Cheese?"
Collaborative activities and process being important is NOT mutually exclusive with many meetings being useless, agile ceremonies time wasting uselessness and design review being used as a place to pontificate about crap.
NONE of the activities you mentioned are activities that lead to what article talks about - well designed spec.
But the flow state wasn't just about typing code. The flow state was about understanding the problem, about loading it into your head so that you could "walk around in it" mentally, so that you could figure out that what really needed to happen was that module X needed to add a getter to value foo, that module Y needed to get foo and make a change based on the value, and that the key to making this all work was to add a way for Y to access X that fit within the existing architecture. That took focus, far more than implementing the pieces did.
I hate meetings when they're mismanaged, which is often. I like a good meeting. Probably what most swes would say.
Just look at what they write. There is a correlation between the Agentic Multitasker and the type of person who wanted results and didn’t care about the coding in itself. That’s what they themselves keep writing.
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.
I would say in general the amount of persons who pivot like that is low.
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.
Welcome in humanity my friend.
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.
no, these meetings are still hot garbage.
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.
Code is a liability.
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.
I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company's I have worked at in the long-term.
> The inability for the business to define a focused, productive roadmap has always been the problem in software engineering.
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.
Any competent engineer should understand that engineering is just the assembly line side of product development. Deciding when to release which feature, bug fixes, etc. and the development/management of the product in general has always been the real challenge, and a lot of the strategy involved in doing this relies on feedback loops that AI cannot speed up. Though at the same time I do feel like leaders on the business side often scapegoat engineer's speed as an excuse instead of taking responsibility for poor decisions on their end.
I get what youre trying to say but this is actually a bad picture to defend. product and engineering should go hand in hand, with one side informing the other. Engineers sctually giving a shit about a product will tell product possibilities they havent even considered, product people caring about engineering will not propose utterly stupid things. and I for one can spot when a product is well designed but poorly made, as well as when a product is perfectly crafted yet useless. the sweetspot is both. and even with the speed multiplier of AI, having a proud in the craft and being actually good in it as an engineer makes a night and day difference for the final result.
> [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway 1967
> I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical.
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.
yes, most places I have worked were hobbled by the organizations being completely idiotic.
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.
It’s part of the problem but AI also can crush this on pure lines of code and functionality alone. It can put out 100,000 lines of somewhat decent code in a day. That usually takes months or years of manual coding for a team.
More lines of code doesn’t help adding more constraints to a system without violating the existing ones.
In fact, it makes it harder.
An awful lot of problems can in fact be solved by 'more code' in fact. People seem to straw man this in terms of product feature surface.
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.
All listed are in service of the product feature surface.
[dead]
Bottleneck for what? More features?
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.
For business, software applications are tools that facilitate "the thing" that generates money. (We in the software world think that _thing_ is software and software _features_, but outside that world, there's usually a different _thing_.)
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.
> 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.
2 replies →
From the article:
> 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.
Should the paradox not be that we PAY more for it? Or, if some process is made more effective, i.e. takes shorter time, we spend more time in that process.
Unit cost is down but aggregate cost is up.
Yes, I believe you are correct (but imprecise which is why the other commenter disagreed with you).
We pay less per unit, but we pay more in total.
No, we pay less for it. But there's much higher demand so overall use goes up.
1 reply →
> Software is what’s left over after a group of humans finishes negotiating with each other about what the system should do.
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.
What kind of projects are people working on, where understanding what features the management wants is the only difficult part and the rest can just be "typed out" (or, today, offloaded to an LLM)? If that's what you do, then I'm not surprised so many people on HN think LLMs can replace them.
Any discussion related to this topic always seems to assume everyone uses code the same way and for the same function, and then forces the rest of the world through that lens.
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.
I've found the more senior you get, the code seems more fungible, and the process seems more important and difficult.
Isn't that just ascribing difficulty to the parts of the process you're closer to?
Uno reverse. What kind of limited project experience would lead anyone to think that there isn't an enormous continuum between code difficulty and organizational problems in the space of software development?
This is like 80% of CRUD apps. Sometimes they have a few interesting problems but not like the upper 20%. Most of them are hot garbage in terms of code quality because of the offshoring and layoff cycles.
Also even the more complex things will have a lot of simpler code in them.
I think the argument here misses critical nuance; there is a difference between code used to implement a product and when code _is_ the product.
It goes without saying that agents have little to no product sense in any discipline. If you're building a game or an app or a business, your creative input still matters heavily! And the same is true for code; if the software is your product, then absolutely the context missed by skipping the writing process will degrade your output.
That doesn't mean that writing code wasn't a bottleneck even for creating well structured software projects. Being able to try multiple approaches (which would have previously been prohibitively expensive) can in many instances provide something a room of bickering humans never would have reached.
> difference between code used to implement a product and when code _is_ the product
Care to elaborate? I don't understand the difference unless you mean code that _is_ the product, being OSS code or code for license.
I think what I'm trying to get at is that there's a lot of code out there that really just needs to work. It doesn't need to scale to millions of users, it doesn't need to be abstract-able and useful to use cases we don't even know about yet, just needs to get an idea off the ground. That code is not the product. In such a case writing the code very much is a bottleneck.
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.
1 reply →
Code you ship vs tooling you use to build the code.
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.
systems vs application code
(not related to the article)
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`
Turning off Javascript made the dot go away.
FWIW I see the red dot only at the top of the page, flashing slowly. It does not annoy me, in fact I only discovered it because of your comment.
On desktop, it's fixed to the left of the story, pulsing along the entire time you're trying to read. If you are like me, it will annoy you. I had to switch to reader mode.
From what I can tell, it marks the article you're on. There are other light grey dots with other article names in it.
I think he's going for a metaphor about groups versus individuals. There are other gray dots around the red dot. Software is a group effort, but made of individuals. Something, Something.
One of the bottlenecks has always been the code. That code has been stolen and is being laundered while companies rely on mediocre engineers who have never written anything of value to promote the burglary tools and call the process "writing software".
It is the same as putting an Einstein paper on a photocopier and call the process "writing a paper".
I agree with the point of the article though: code generation does not really work, the results are bloated and often wrong and people already had more features that they could absorb in 2020.
The solution to this mess is to have 18 year olds boycott studying computer science altogether, since the industry (and mediocre fellow "engineers") will treat them like human garbage.
Personal anecdote. When I started as a wide-eyed university co-op, I was surrounded by a team of aging mainframe developers who had been coding since the 1960s. Their backgrounds ranged from working their way up from the mailroom to astrophysics to masters degrees in computer science. What struck me was how the entire team treated coding as a form of art. Of course, it had to be functionally correct and maintainable, but you could glance at a snippet of hyper-efficient PL/1 and instantly tell that 'Larry' or 'Trudy' wrote that routine - each programmer had a unique style, along with just the right amount of comments to make you laugh and guide you through difficult bits.
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.
My status after reading your comment: https://imgflip.com/i/7yki7x
Agentic tools are "burglary tools" -> Younger folks should not study CS?
I think the solution is to fix society so that we value quality over quantity, self betterment over getting rich, and making society better for every one rather than worshipping billionaires.
Everything in life revolves around people, and even more so today
> Producing easily consumable context is precisely the thing humans don’t like to do.
I don't think this sentence speaks for me. This is the sort of thing I love to do.
Doesn't add up. I used to spend more than half my time coding, as did others. Besides the obvious cost, that coding took wall-time which meant talks had to wait. Sure a poor collaborator will jam things up a ton, but a team of at least ok collaborators used to be bottlenecked on code.
> They are waiting on the next well-formed spec
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 problem with this is that everybody thinks they have better ideas than they do. And engineers are probably the worst offenders in that they're smart enough to make a case that deludes themselves.
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.
Totally agree, we wrote our own piece similar to this: https://productnow.ai/blogs/teams-that-coordinate
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
“Something went wrong with the editor” when loading page
Sometimes code is definitely the bottleneck. For example some organizations have a very bureaucratic process guarding which projects get access to a development team and when. That's not needed if implementation is now faster/cheaper.
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.
Can someone explain the title? I think the author illustrates that the code was the bottleneck and it has shifted to context. What am I missing?
I think he is saying, I hope he is saying, that software has never been writing software, it has been communications with people over what the software should be, needs to be, and the entire point all along has been to achieve better collaboration with people, and implied: to achieve their collective goal. He spends a good amount of time on how slow writing software has been in the past, and that allowed the industry to over focus on the software writing. While it has been pointed out a number of times by milestone books our industry embraced that it is the communications aspect of why and what we write that is the most important. Finally now that is being forced upon us because writing code is now automated, and all that is left is the specification and the communications with humans over what and why.
The author argues that writing code cannot be a bottleneck because work always fills up the allotted time. Developer teams should instead focus on doing less and writing better specifications.
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.
I think the point they're trying to make is that context known by humans and the requirements they agree on, is 'the' bottleneck, rather than implementation
Absolutely matching the gut feel I've had lately. We've always been pretty good at producing bad code very fast. All of the other stuff - dependency management, learning what's valuable, ownership & boundaries, context switching costs, etc... have always been the bottlenecks and it's just more obvious now.
So managers are overwhelmed because the code is now happening a lot faster? It sounds like the immediate bottleneck really was the code, at least frequently. Now it seems the bottleneck is managerial.
> Agents that consume context need agents that produce it. Once that loop is running, the organization has a written substrate it would never have produced on its own.
I'm not sure a business is helped by documentation that distilled from (hopefully present) PR descriptions and comments in JIRA, by agents. Or wherever this context is supposed to be reverse-engineered from.
[flagged]
The company website linked in the article is broken https://www.dottxt.ai/ on (mobile and desktop) Safari. Looks like your cert doesn’t cover the www subdomain.
Velocity, velocity, velocity! Ah yes, velocity always seems to matter except to those that don’t need to worry about it.
The bottleneck has always been the human element. I too used to be one of those up-my-own-ass engineers who thought the most important part of my work was the machine, and it wasn’t until I began actually listening to others and their problems that I realized my function was far more than mere technology scaffolding.
That said, I’m also increasingly aware that puts me in a minority group. I got to see this first hand in a recent org where their codebase and product design hadn’t meaningfully evolved in nearly thirty years. NAT was a “game changer” to them - and one they refused to implement without tons of extraneous testing they would deliberately undermine, stall, and sabotage so they didn’t have to modernize their code accordingly. It was easier for the developers and stakeholders to preserve their own status quo rather than entertain alternatives, to the point of open hostility (name calling, insults, screaming, and a few threats) to anyone suggesting otherwise.
The human element has always been, and always will be the bottleneck. Stakeholders who don’t contribute updated or accurate datasets to automation systems, or who hold back development to preserve personal status and power, or who otherwise gum up the works on purpose to game their own careers.
That’s not to make the argument of “replace all humans with machines”, mind you. Just stating that an organization that incentivizes bad behavior will be slowed down versus ones that incentivize collaborative outcomes, and AI is just going to turbocharge that by removing the friction associated with code creation and shifting that elsewhere.
> name calling, insults, screaming
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.
I was already looking, but they ultimately made the decision for me in January with a RIF.
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.
the bottleneck was never the software, that is the ship we ride,
people, are part of a team focused on a goal, they work together because they believe in that the ship is worth riding on and will reach its destination,
the ship should carry food people want,
team decides what food will be consumed,
captain tries first the food,
if food is good and people want it, people buy more
> Real programmers don’t document their programs.
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.
> Real programmers don’t document their programs.
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.
I can see the division here already, and the cogs are afraid. As a dev of 25+ years, currently working for a small company who came from a global company, I see both sides. I'm very excited about AI and love to see my projects come to life so much faster. I still love the craft of code, but its always been about the product for me.
The paper hits the nail right on the head, but it misses the mark on the next constraint: how to decide what to build.
In the old days when writing code took up a lot of resources, the constraint was self-correcting since being off in your implementation was obvious enough that the error could be easily seen after three months of work on the wrong feature. Today, you could spend five wrong efforts in the same amount of time that it used to take you to implement one wrong effort.
[flagged]
See also https://wesmckinney.com/blog/mythical-agent-month/
For me it was. Solo entrepreneurs are the ones who profit the most from AI assisted development.
Or startups where coding was always a bottleneck because it was very expensive to hire swes, unlike big corps which would often throw swes at a problem.
If thats true, I am sure some C-suite manager knows this already. Assuming management knows what they do, after all, they're getting payed for this. The time where engineer are trying to educate people above them should be over. Management gets payed for the big decisions. If they tank the company, so be it. I no longer care.
> What may save us it that agents are unreasonably good at reading exhaustively. An agent will read every PR comment, every closed issue, every commit message, every stale design doc ...
> 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.
It also bakes in the LLM quality at the time the documentation was generated, into the documentation. It potentially worsens the performance of future LLMs if they ingest the documentation produced by older LLMs. It’s not clear why documentation wouldn’t instead be generated on demand, using the newest SOTA LLM.
It seems like so many developers know this, yet here we are. SV pushing this AI slop economy. More code! Faster! Less testing! Less understanding! It's what we NEED!
[flagged]
[flagged]
[flagged]
[dead]
I cringe every time I read the word "load-bearing" in an article.