6 ms·
Engineering management after the cost of code collapsed
- cineticdaffodil 2mo agoCan a llm predict the price of a change to a codebase in tokens and predict the origin of the price, aka cam it see good and bad architecture?
- mathgeek 2mo agoAsk it to do so, would love to know your results.
- deleted 2mo ago[deleted]
- cineticdaffodil 2mo agoI did, the problem is that you need a sort of standardized feature change to compare similar repos. So the metric is relative only to same projects lacking that same feature. So no, its a useless thing. No architecture score comparisson between apples and oranges.
- cineticdaffodil 2mo agohttps://chatgpt.com/s/t_6a64f4a6e86c8191b41cb6a810359208 https://chatgpt.com/s/t_6a64f4a6e86c8191b41cb6a810359208
- arjie 2mo agoSome code bases better than others but the top models can.
- coffeebeqn 2mo agoSure and having some in repo documentation markdown makes it a lot easier
- j45 2mo agoSoftware development has always evolved. Sometimes slowly, sometimes quicker. LLMs have brought a different unlock, and for everything we're seeing become easier, it allows people learn to use the tools to take on solving problems that couldn't be approached before.
- glimshe 2mo agoYour short post speaks of exactly what people should be talking about. Due to the panic related to job replacement, not many are talking about the new frontiers. Vibe coding is boring because it does the same faster/cheaper. I'm more interested in the things we couldn't do before but we now can because there's a crazy savant a few keystrokes away.
- j45 2mo agoAppreciate it. The focus is placed by those who ask question and have a platform, and most don't have a tech background let alone implementing tech or software in businesses.
- CurbStomper 2mo ago[dead]
- antonvs 2mo agoThe worse problem is blog posts after the cost of writing collapsed. Not everything has to be written as though it’s a middle manager’s idea of what makes for a good TED talk.
- aplummer 2mo agoI read this entire article and didn’t sniff AI, plus it had some good insights…?
- nwah1 2mo agoFeels like a human-authored outline that was run through AI to make it into an article.
- hgomersall 2mo agoWell it contains a typo, so it made a cock up.
- ilovefood 2mo agoI've written this myself, Gemini 4 did a bit of editing: > What follows is a cleaned-up version of notes I accumulated over the past year. Gemini 4 helped with the editing. The image is made by an AI image generator on fal.ai. It's better I spare you all my design skills :)
- 2mo ago
- mgaunard 2mo agoThe cost of code actually increased; code debt is being accumulated faster than we can clean it up.
- VeninVidiaVicii 2mo agoYeah but look how much there is! Aren’t you impressed?
- leptons 2mo agoWe still pay our software developers the same amount, but now an AI is the middleman taking more and more money (in the form of tokens) every day. With every new model, more tokens are consumed so the new model can "think" more. Nobody's even really reading or reviewing the code the AI produces, so software quality goes down, and we're paying more to produce it. And when there's a serious problem with the code? No human is going to dig through the mess the AI created - so burn even more tokens/money trying to get the AI to fix it, or just start over from scratch again with the AI, hoping for better results. It's the definition of insanity. I'm looking for a new job, maybe even a new industry, a new career path - after 30 years in this industry, software development is jumping the shark.
- thih9 2mo agoWe’ve already lived through multiple floods of unmaintainable code, eg with unstructured JQuery. New tech stacks will appear and they will handle the mess to some extent.
- oenton 2mo agoAs someone who hadn't used JQuery extensively because I came into the industry a little bit later when others like Prototype, Backbone and Ember were just starting to phase out, I have a lot of respect for JQuery. Or perhaps I have a lot of respect for the problems that JQuery solved which we now take for granted, like AJAX requests. With this and the pipe dream of continuous generation and deployment of code without a human in the loop, I can't even think of a problem it's solving or attempting to solve. The closest thing I can think of is library or language upgrades... but we already have automated solutions for those e.g. codemods and migration scripts.
- jboss10 2mo ago> Gemini 4 helped with the editing. Does this guy have access to Gemini 4 already? I'm guessing Gemma 4 was happy to be mistaken for Gemini and didn't catch this mistake.
- trollbridge 2mo ago“Helping” is doing some heavy lifting in that sentence! It appears to be 100% AI.
- dualvariable 2mo agoI couldn't get through it. I find it exhausting trying to read anything that smells remotely like linkedin AI slop at this point.
- ilovefood 2mo agoYes correct, Gemma. Will correct it shortly.
- add-sub-mul-div 2mo agoYou don't build credibility by putting out slop and correcting it every time someone points out that it's wrong. You think it's our job to proofread and fact-check?
- ilovefood 2mo agoA genuine mistake. I make these posts for myself, mainly to structure & share my thoughts. Let me know if you find other errors, I appreciate the feedback.
- dataplumb3r 2mo agoIf you wrote an initial draft you should consider using a better model or just posting what you wrote. The smaller models can be sufficient for coding but for document writing not highly specific I've yet to be satisfied with AI output. I certainly wouldn't expect gemma to produce good outputs.
- baron3dl 2mo agoWhat is the right, best software organization in the current era of AI coding? This question is critical and wholly unanswered in comprehensive research along the same axis as Accelerate (2018, Forsgren, Humble, Kim). There are a lot of (excruciatingly) long-form posts about what folks are pioneering but not a whole lot of follow up about what failed. Where are the short posts on the negative space? How did halving your staff work out? Flattening your org? All those dark factories, what haven't they produced? How about all the other things tried, failed, and unceremoniously scrapped? We need to explore and communicate the negative space more efficiently. Don't repeat the same mistakes, and don't make me read 2653 words when 300 do it better.
- VeninVidiaVicii 2mo agoHard to say what caused what, but the internet seems to mistake verbosity for authority, and so does AI.
- baron3dl 2mo agoA tech comm course I took in college was graded on two 20-page papers and accompanying 5-minute presentations. That was like 10k written words in a single semester. It was a challenging class, and gave me substantial sense of accomplishment, just to hand in completed work. Similar to a functioning side project in the 5-10k LOC range. Announcing something that worked a year ago, was laudable, even if not profitable. I vibe coded 15k LOC this morning and read 20k words of AI generated text while doing so. No longer are either noteworthy or valuable public contributions just by virtue of having been done. I don't think that's widely recognized yet.
- tempodox 2mo ago> I don't think that's widely recognized yet. The recognition is represented by one word: Slop.
- w10-1 2mo ago> mistake verbosity for authority Isn't that the essence of "attention is all you need"?
- trollbridge 2mo agoPangram reports this post was 100% AI generated.
- bonzini 2mo agoIt's depressingly hard to find one that isn't. You see the title, think this might be interesting, and puke by the second paragraph.
- ilovefood 2mo agoI'm really open to feedback. I checked your past comments and you posted: > AI is good at coding if there's an oracle. If the system is ancient, unreadable, untestable, that's exactly the opposite. It won't get the exact set of corner cases. I sort of mention this in the article, so I'm sure we're somewhat aligned on the core. How would you have worded things?
- bonzini 2mo agoFirst of all I want to say it is not your fault, and also your article is clearly partly human, despite what Pangram says. The thing that I like the least is the headings and the way LLMs always try to put a punchy line. "Correctness time splits in two" says nothing if you don't know what it splits in. Maybe "making it correct vs. describing what's correct"? Another trope is short sentences: "Good engineers used to say this before LLMs, and now nobody can argue about the sunken cost of having written that code." instead of the longer and redundant "Good engineers said this before LLMs. It was true then. It is enforceable now in a way it was not, because nobody can argue that writing more code was the hard part". Another clearly AI paragraph is "Plumbing time collapsed. Scaffolding a service, generating tests, translating between frameworks, writing the first draft of a migration: all of this is fast now, and any timeline built on those costs deserves compression." Instead: "The time to bring up a proof of concept or refactor old code has compressed, and you should take that into account when planning your timeline". There are videos on YouTube about AI style, you just need to learn them and undo them when they're the most blatant.
- deleted 2mo ago
- marginalia_nu 2mo agoCode was very rarely the bottleneck in the first place. If programmer productivity was something we actively optimized for, we wouldn't have crammed programmers like sardines in warm and noisy open floor offices with 2000 ppm CO2 levels and then further constantly interrupt them with emails and slack pings and meetings all day long, Jira rigmarole wouldn't make up a significant portion of what they did, programmers would have instead mostly been thinking and programming. We've always had the ability to 2X if not 10X the output of each and every one of those poor souls. You don't end with this sort of programming purgatory because it's a productivity optimum, it very clearly isn't, but because it's a billable hours optimum and/or an org chart clout optimum and/or because of Jevons paradox got hands even in business management and the IT department was allocated too many dollars.
- raverbashing 2mo ago> Code was very rarely the bottleneck in the first place. I disagree. Kinda What AI has made much simpler is that you don't have to waste time checking docs and have the best autocomplete system by a long shot - this was a bottleneck unless you were doing Java or some other language with "perfect" AC What AI made "kinda easier": solving for usual problems. The stuff you would search Stack Overflow, or think a couple of minutes for an optimized solution - not a bottleneck but not 100% smooth neither You still have to test and validate your code. AI made this easier-ish but this is still where I see manual work being needed (even if you are automating tests - you still have to think on what you want the code to do)
- marginalia_nu 2mo agoThis just says that we can output code faster. I'm saying that the rate at which we output code wasn't the thing that was slowing down development. We've always been able to increase that even without AI by adjusting the working environment and removing obstacles to programming. In larger organizations, quite often it's the business that is holding back development. They can only handle so much change and speed needs direction to be velocity. Drafting requirements is generally much slower than implementing them. Like the number one complaint from programmers has been that they don't get to do programming. They want to write code, not update jiras or spend hours in meetings.
- happytoexplain 2mo agoCode was never expensive.
- doug_durham 2mo agoCode was always expensive. Entire industries of design tools cropped up simply to avoid writing the wrong code since it is so expensive. There are entire journals dedicated to this. Organizations are fixated on making sure that the right code is written since the cost of getting that wrong is so great.
- mathgeek 2mo agoI assume GP meant exactly this (the people designing and writing good code are expensive).
- SoftTalker 2mo agoBuilding the wrong thing is what is expensive. Once you know what you are building and can clearly describe it, the code isn't the hard part. Or at least that's how it has always seemed to me.
- mohamedkoubaa 2mo agoAt least not the writing of it
- siliconc0w 2mo agoI don't think it changes much for good managers. It should always be able setting people and processes up so the team can land durable measurable impact. The managers that thought the job of software engineers was to write code were bad managers. PRs or LoC were never good metrics.
- ilovefood 2mo agoAgreed, which is why I also believe "token usage" and similar proxy metrics aren't the right ones for what's next.
- dbingham 2mo agoI think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally rewritten. LLMs still aren't good at writing maintainable code. Can they write plausibly functional code? Yes. But it won't survive the long term. People using LLMs to write all their code are gambling on them eventually getting to a point where the LLMs can fix their own code. It's possible, but I wouldn't necessarily bet on it. Where I have found immense value from LLMs is in code review. Repeated review by LLMs catches an amazing amount of potential issues. They really shine on security review, but are very effective with any kind of review. The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck. Understanding was. And understanding the code is still the bottleneck. But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing. Most of the time previously spent writing was actually spent updating and deepening our understanding of the system under development. There's no replacement for that understanding in a world where LLMs are doing the writing. But if you flip it: humans write, LLMs review, then you still get a major gain -- not in speed, but in quality. And you keep the understanding loop intact. I would propose that this might be the best way to deploy LLMs.
- lukan 2mo ago" But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing." Debugging code step by step is how I understand complicated code.
- dwayneII 2mo agoI write code in Go in an established codebase. 90% of the time the LLM gets a basic api/feature right and fully e2e tested as long as I give it enough business context in the prompt. The other 10% of the time I have to do some follow up prompts to either change the behaviour or change the approach of a given step in the flow or just to point out that the wrong pattern was used and please rather use our codebase standard. I haven’t actually hand-written code in well over a year. Is this way faster? Absolutely. Does it lead to better code? Yes, because I have time to write all the regression tests that keep the behaviour as I wanted it when others come bungling around.
- georgeburdell 2mo agoIn my experience, management is mostly pissing away the gains made by AI by either: 1. Pursuing polish and quality beyond previous norms 2. Replacing $100/mo/seat SAAS with something coded by a junior costing $200/day to develop over months. The cost of code approaches zero, but the cost of having accountability, and hosting remains the same, and so individuals need to only coordinate to the extent that those things remain finite resources. Management needs to stop insisting that their directs adopt each others vibe coded tooling.
- sanderjd 2mo agoI think #1 is quite a good thing, on net.
- raffraffraff 2mo agoMy take, as a non-coder (well, not software engineering, I write 'code' but it's infra, and utilities in go/bash/pythong)... I work at a company where the biggest problems are not 'writing code', they are: - Organising teams - Designing the system - Prioritisation of work The fuckups that we make on a daily bases are not 'code errors' they are failures in THOSE three things. I'll go into detail if anyone cares.
- convolvatron 2mo agodon't forget 'actually making decisions'
- sanderjd 2mo agoSame as it ever was.
- treetalker 2mo agoGenerative language models have helped me most by drawing my attention to the importance of context, communicative compression, prompting, comprehension, coherence, and coordination in the domain of human groups.
- raffraffraff 2mo agoSame. Our engineers have failed to convince absolutely clueless executives that service / code ownership is critical, you can't just allocate 100% of your engineering team to "roaming around the dungheap adding features" because they want everybody to focus on features. In an organisation where nobody owns anything, nobody cares about anything, nobody has the autonomy to fix anything. Imagine a huge wobbling Jenga tower with dozens of engineers all trying to pull out a block, put it on top and back the fuck away quickly, hopping it falls over after someone else touches it. Yes this is real. And it's hell. And now all of those Jenga players are AI powered.
- cindyllm 2mo ago[dead]
- phrones1s 2mo ago[flagged]
- lardosaurusrex 2mo ago[dead]
- tiago_human 2mo agoAI reduces the cost of writing code, but it makes adding things that nobody uses even cheaper. The bottleneck then becomes deciding what deserves to exist—and having the discipline to remove the rest. So this will imply more time spent in code reviews that lead to more iterations in PR's. AI is doing a good job on writting code these days! Nothing against it; I use it every day, but the context switching is costing us a lot!
- stefangordon 2mo agoI’m struggling to imagine a project that would require more than one talented engineer and a bucket of tokens anymore. I think perhaps the assumption that engineering managers should have any employees may be outdated. I can imagine average and mediocre engineers equipped with tokens could create chaos and debt on a scale never before imaginable, so it’s easy to see how orgs who still have these employees around are struggling with the transition. The reality is you need to get rid of them all, and replace them with the most experienced highest paid person you can find. In the near future that person will become obsolete too.
- chrisjj 2mo ago> I’m struggling to imagine a project that would require more than one talented engineer and a bucket of tokens anymore Try air traffic control?
- chasd00 2mo ago> I think perhaps the assumption that engineering managers should have any employees may be outdated. to me, the latest models and harnesses turn all devs into an engineering manager with one direct report. Some devs naturally take up the role and great things happen, for others it's like trying to get a fish to ride a bicycle. This is how it was pre-genai too so i don't think there's a right or wrong answer, some will take off with the technology and some will struggle.
- sdevonoes 2mo agoWould that single person handle different topics such as: UI/UX, security, backups, distributed systems, data migrations, infrastructure, …? Sure thing there are engineers out there that know some about all of the above (I personally do all of that on personal projects) but you still need specialists, otherwise it’s you alone with all the unknown unknowns that the llm may claim to solve, but you cannot verify
- chrisjj 2mo ago> The cost of producing plausible code has collapsed Who wants merely plausible code?
- devin 2mo agoYour director who is burning tokens making a POC you now need to figure out how to support at scale.
- whinvik 2mo agoSorry, "Gemini 4 helped with editing"?
- 0gs 2mo agodang it i tried to check for a dupe but there were too many comments!
- 0gs 2mo agoGemini 4 eh????
- OutOfHere 2mo agoEngineers do not need management. Investors do. As I understand it, the purpose of management is to match financial resources with material+human resources to perform feasible tasks. There is nothing here I see that can't be done by an experienced token generator. If anything, automating management seems easier than automating engineering. As for leadership, it can be done by the investors.
- visarga 2mo agoYou can automate work but never owning the consequences. AI tasks emerge from human contexts, they perform work in the context and finally the outcomes collect in the context - gains, losses, risks, costs. So AI is great but it needs our skin for the start, middle and end of a task.
- OutOfHere 2mo agoIt's not as if management owns any consequences. At best they adapt, but so can AI. Management tasks are not like engineering tasks.
- pillefitz 2mo agoAs stated in the sibling comment, management is very similar to engineering.
- OutOfHere 2mo agoOf course management would like to make that claim, but I don't see it substantiated. In what way is management "owning the consequences" -- are they losing their equity or risking an unpaid suspension?
- pillefitz 2mo agoThis is such a simplistic view I have difficulties deciding where to even start. Think of a manager as someone who engineers the fabric of the organization. Most of my time is spent debugging, communicating, finding the right abstractions, configuring processes - all very similar to the engineering work I previously did.
- 2596-ANXC 2mo ago[dead]
- vips7L 2mo agoI miss when this forum used to talk about computer science and programming languages.
- 650 2mo ago"Shield the team from the business." The assumption underneath this one is that attention is finite and context switching is expensive. That assumption is intact. What changed is the cost of starving the team of context. Engineers prompting AI tools without business context just produce fluent, plausible, wrong work, at scale." Too many teams and organizations have business types, mostly PM's who seek to lord over their area of know how and see themselves as delegators and mini CEOs, actively avoid looping engineers in to validate themselves. Engineers need to take on PM roles, and the PM role needs to be 1:50+ eng or go.
- jdw64 2mo agoCoding used to be an expensive task. Seeing how quickly repositories have grown with the rise of AI coding, it's clear how much people wanted to build things but were thirsting for the means to do so. Even languages like R, which were mostly used by graduate students and experts, have seen a massive increase in usage since vibe coding became popular. Honestly, when people say AI code quality is bad, Linus himself has said it's now genuinely useful. AI is useful and writes better code than most people. Even in competitive coding, tourist lost to AI. And in the most logical field of all, mathematics, AI is churning out an enormous number of theorems. Looking at all this, it's fair to say AI is at least at a PhD level of technical ability, and most people would admit they don't have PhD level skills. Of course, there are still many people who code better than AI. But at least when it comes to unfolding logical structures, AI has a higher chance of being more logical than humans. Within a given framework, AI constructs much more logical structures. That's why I think the article's use of the word 'semantic' is right. It's humans who form the framework, and that's the semantic, while AI fills the empty spaces inside it. If you feed it a flawed framework, it fails. And the fact that AI is more logical than humans is paradoxically a greater risk. Human developers can rely on tacit knowledge to make reasonable compromises even when the requirements, the framework, are sloppy. AI can't do that. If there's a logical gap in the framework humans design, AI will exploit that weakness and expand the state space into regions we can't cognitively grasp. Programming is ultimately about how you occupy state space. The problem is that as the program grows, the cognitively inaccessible territory keeps expanding. So we distribute trust across reliable points, libraries, frameworks, and for my own code, once it exceeds tens of thousands of lines, I rely on tests and gates. Honestly, the idea of understanding everything in a program is a purely academic claim. Once the program gets large, it's impossible. No one can know every external factor, test bug, or unexpected interaction. The issue is that with LLMs, when the prompt input goes deeper into the semantic space, it also reaches into areas I don't understand, producing code at a depth that's untestable. For example, I might be an expert in domain A but a beginner in domain B. If I inject expert level knowledge for domain A into the AI, the AI will try to match that level in domain B as well. That results in code I can't understand or modify, and eventually, I'm left with no choice but to replace all the code with AI generated code. So I'm wondering what to do about this. Should I focus on gaining empirical experience in handling black boxes? Or should I stick with smaller, human written codebases? But realistically, the current situation, where I can build bigger and touch more things, is more enjoyable to me. I think what I actually enjoyed wasn't programming itself, but the act of creating something.
- chickensong 2mo ago> Sorting requires a model of how your org actually behaves: trust relationships, hallway knowledge, the consequences of past decisions. Almost none of this is written down. This is a long-standing problem related to operational excellence and politics. I expect this will improve with AI adoption and integration. You can't get an exec to create a decision record and commit it to git. Managers have incentive to sequester information. Engineering already has the discipline (maybe) and abilities to solve the problem. Version control, change control, ADRs, logging, structured docs, etc... We can trace an inbound packet or call through the entire stack. Management can't/won't do anything remotely close. 1-to-1 emails, meeting minutes, stale Word docs is the standard for most. Inserting LLMs as the interface, and/or plugging into existing interfaces like email, is going to change things. Finally it will be possible to capture more institutional knowledge, without trying to teach an old dog new tricks.
- matthorse 2mo ago[dead]
- 1over137 2mo agoThe cost of code has collapsed? Have programmer salaries gone down?
- Mohiuddin7 2mo agoi agree with that but now at the pace where everything is moving really really fast, humans are using ai tools n all for imensively writing code and building new feature where they are also facing issues and frustration while debugging...llms are really good but sometimes they catch the issues but majority of time, they just grep or bash the things and eventually ending up not losing context....but if we go with your proposed way, then if humans build n llms review then it will be the slow process.....Hope I put my point correctly
- teyc 2mo ago“Shield the team” from context switches, not context. Cached context is cheap
- mikewarot 2mo agoTo clarify, this article is not about the practice of Engineering [1], nor the management thereof. Words have meaning, and I strongly feel that clarity here is helpful. An engineering approach to software development would include rigorous testing and require individual signoff for every library and module. It is quite clear that an LLM would not be able to meet this requirement. When casting about for ideas or prototypes, the throw away nature could allow their limited use. [1] https://en.wikipedia.org/wiki/Engineering https://en.wikipedia.org/wiki/Engineering
- aivengo_mk 2mo agoFor you as supervisor not much has changed. Before you had juniors not having full context, hesitating to ask, focused on code. Now lying agents, pretending to have phd grade but taking dumb choices here and there. Trust but verify as Lenin was saying.
- ParityBear 2mo agoNothing has changed. I worked under this guy at some point in the last year while working at a very questionable cryptocurrency company with a very questionable CEO (doesn't narrow it down too much). The author of this article was awful. Pure toxicity. He gatekept all information and no one under him had any context until the CEO would complain and he would blame his underlings. He would set teams working against each other on the same problem with neither team knowing. Many people working in his vicinity quit. He would have tirades in open group chats threatening to fire people outside of his department. I saw him trying to get views for this post on LinkedIn so I had to come and check the comments. Seeing this article is pretty funny though. Seeing "Shield the team from the business." is pretty funny not only because he would gatekeep context, but also because the company he has worked at for the last several years has no business model. It is a pet project for a founder who made too much money for his own good during the cryptocurrency boom. And since the author has been there the value has dropped something like 95% or more. His department was outputting so much AI slop proofs-of-concept and then handing it off to other departments to maintain, and then passing off blame for future issues while taking the short term wins. I am so happy I am out now.