Code takes 6-12 months to make it from commit to production. Development speed was never the bottleneck; it's all the other processes that take time: infra provisioning, testing, sign-offs, change management, deployment scheduling etc.
AI makes these post-development bottlenecks worse. Changes are now piling up at the door waiting to get on a release train.
Large enterprises need to learn how to ship software faster if they want to lock in ROI on their token spend. Unshipped code is a liability, not an asset.
So much of Management (both mid and executive) still considers Software as if it were an assembly line; "We make software just like how Ford makes cars". Code as a product.
Which isn't to say that most software development isn't woefully inefficient, but the important bits aren't even considered. "The Work" is seen as being writing code, not the research that goes into knowing what code has to be written.
And for AI marketing, this is almost a videogame-esque weakspot. Microsoft proclaims "50% faster code!" and every management fool thinks "50% faster product; 50% faster money!"
> Large enterprises need to learn how to ship software faster if they want to lock in ROI on their token spend.
It's going to be a disaster once ROI is demanded. Right now everyone is fine with not measuring it; Investors are drunk on hype and nobody within the company actually wants to admit that properly measuring software development productivity is almost impossible.
But the hype won't last forever. Sooner or later investors will see the "$2M spend" and demand "$4M net profit", and that's not going to materialize.
Copilot and Claude won't be tackling the real bottlenecks. They're not going to dredge up decade old institutional knowledge, they won't figure out whether code looks bad because it is bad or because it solves a specific undocumented problem, they won't anticipate future uses.
Code just isn't the product. Not the real work. Really, if your codebase is in a healthy state, it's often a literally free output of the design and research processes. By the time you've refined "our procurement team finds the search hard to use" into a practical ticket, the React component for the appropriate search filters has basically already been written, writing up the code is just a short formality. Asking Copilot would turn a 10 minute job into a 5 minute job. Real impressive, were it not for the 6 hours of meetings and phone calls that went into it.
People who say this kind of thing probably have no idea how Ford makes cars either. The assembly line is the last step. All the research, design, engineering, and testing happens before any sheet metal is stamped out. So the comparison might be more true than not, but unknowingly.
I think the point OP is trying to make is that manufacturing and design are seperate steps with different workflows and expectations. And that the design step does have value, as without it your factory line has nothing particular to make or sell.
Nobody is sitting around Ford trying to make the clay modeling step faster or more error free, it's a design function. But there are hundreds of software execs out there trying to do exactly that. In part because cp and git and make and your other build tools that make up the factory line function are pretty much rock solid and cost optimized to nearly free.
The design, factory, supply chain, etc. is just the marketing arm for the loans...
It was a short pithy sentence, but it does have a kernel of truth to it.
Little-known fact, cp is actually an AI. I trained my cp AI on a copy of the gcc source code and asked it to write me a C compiler and it did! It was so accurate it even managed to reproduce gcc's bugs and quirks.
Does that apply to phones?
I think this is probably going to happen at the same time that the providers start really jacking up token prices to extract all the value they can.
I can't answer that question but plenty of other managers are fully ready to just give bogus numbers.
For my team, use of AI has indeed lowered the story point cost. The coding part of the story takes less work so we have started to lower the story point cost for stories that would previously cost more. Think of a 5SP to 3SP reduction.
We have increased the number of features being delivered but our number of story points delivered has remained static.
And I'm not opposed to using story points, they have some utility within an agile team or program. They just aren't a valid way of quantifying productivity changes.
Our manager brought us into an all hands meeting and kind of read us the riot act because now we were on "Bob the executive" radar because it looked like we really weren't delivering much week by week. Had anybody actually looked at the amount of work we were doing and what we were shipping, it wouldn't be close.
Exactly as you predicted, we started over inflating our stories, creating Epics when they weren't needed, breaking out a single feature into a dozen or more stories. Over the next few weeks, we were all getting pats on the back for "really picking up the pace". When in reality, we were just doing the same thing we always did.
It just reinforced the idea that Agile had turned into a system that was easy to manipulate to create the illusion you were doing more than you really were. I imagine we're going to see a lot more of this as C-Suite folks start clamoring for ROI on the millions they're spending on tokens.
It should not have. At least not significantly. Points should represent complexity, risk and overall effort (review burden, testing burden, dependencies, etc.), and so AI should increase velocity before it decreases story point estimates.
Over time, if a team's baseline delivery model genuinely changes, then reference stories can be recalibrated, but casually saying "AI lowered the point cost" is usually a smell that points are being treated as time estimates.
This is the same reason points should not = days even without AI. Velocity is what tells you if a team is getting better through training, tooling, hiring/firing, or process improvements. Re-pointing the same class of work downward hides the gain.
Some variant of this has been the case in every agile team I've ever worked on.
So what is it then? All the explanations and examples are in units of time, but with a disclaimer saying that the true nature of story points is not time-based, except for the fact that they can only be explained in terms of time.
The managerial goal is to take near-past moving average rates (from completed tickets) and use them to forecast near-future expectations. 1.0 of Team Alpha's points might mean 4 hours this week... but anybody who shows up six months later expecting exactly the same rate is foolish, doubly-so if they expect it to be the same across teams, or after a big change in staff or tooling or project.
______
Other musings: Whenever a manager says "my current estimate of the rate is X pts/hr, use that when sizing", I feel it's a mistake. I kills off the intuition you really want to capture. Team members ought to be comparing expected tasks to past tasks.
Also, the goal of "accurate scheduling predictions" exists in conflict with "measure employee output". Trying to use your point-system for one generally harms the other.
I've also seen a supplier who was asked to provide some kind of tracking, where literally nothing existed. Their delivery team produced reports with story points per person, per task, per sprint. Every sprint, every person hit their target month after month after month. They were asked to stop.
So a story might be estimated at 3SP to implement but there's a high risk that it would blow out (e.g. idea was not fully proven in a PoC, work is in an area that is historically underestimated, reliance on a different team, etc.), so we set it to 5SP to include that risk. Maybe 50% of the time it does get finished in what a normal 3SP would finish in, but at least we've covered the 50% of time it blows out.
Over time it becomes "priced in" to the moving average, which is good, assuming that employee instincts are generally valid.
Of course, if someone makes the mistake of trying to peg points to time, they're indirectly creating a kind of inflation: Yesterday's "just in case" premium should not become today's "everything goes well" baseline.
Right now the subscriptions are still in the range of reasonable business expenses, but pretty soon they'll have to jump and $200/month/seat subscriptions turning into $2000/month/seat subscriptions is going to get even very badly ran companies to re-evaluate.
We're already here even. I know of a company that was doubling their Codex spend and hitting the cap week over week and finally they had enough and stopped increasing. Then they maxed out on credits and had a week of no Codex. A large percentage of the engineers loudly refused to work for the rest of the week. They were managing the Codex managing the codebase and were totally incapable of dealing with its output without it.
Worse—they'll get the people who hold that knowledge laid off, and at least 50% of the institutional knowledge won't be documented anywhere that even could be fed to the LLM.
Which, it should be noted, is the dumbest idea ever. The Ford assembly line makes more-or-less identical copies of the same design. How do you do that with software? The cp command.
If someone thinks like that, they probably read some business book and either didn't understand the book, don't understand their own business, or is following some guru who has one of those problems.
Software is less like an assembly line and more like plumbing:
Some people design which type of pipe needs to be routed from here to there.
The implementor actually pipes the outputs of one function, in a variable, and then taps it off as an argument to another function.
Software development is like plumbing really, so a good manager of a pipeworks and plumbing company might actually make a good manager for software companies as well.
This is also why its actually not so surprising that LLM's are mastering programming skills, it's essentially just being a plumber, and a lot of people are happy they no longer need to be a plumber. Physicists, engineers, scientists, ... they have much more complicated tasks compared to plumbers, programmers and code monkeys.
Physicists, engineers, scientists, ... they have much more complicated tasks compared to plumbers, programmers and code monkeys.
No, wrong again. Some software development tasks are like plumbing, but that misses a lot. Your claim in sort of like saying since the Wendelstein_7-X has wiring, the manager an electrical contractor would be good to lead that project.
Plumbers and electricians more or less solve the same problems over and over with slightly different parameters, and because of the repetitiveness, they can do a good job by following (a hefty number) of rules of thumb (the building code). A software developer isn't going to go far just throwing design patterns at a problem (though many bad ones try).
Just the other day I needed to make a calibration interface for a home automation app (pointing a dumb webcam at my washer and dryer so I can tell if they're done without running up and down two flights or stairs). I just wanted to be able to look at the whole scene and manually pick the ROI to extract and display on my home dashboard. So I asked the AI to build me a stupid little web UI where I can just click to select the ROI center, and what it built me in 10 seconds was perfect for my needs.
Was it pretty? Not really. Was it what I would have built myself? Not quite - but it solved the problem I had without me needing to remember or look up how to do all the specifics.
The machines all beep when they're done.
A baby monitor in the machine area will accomplish the same thing :-)
But of course the project is much more fun ...
I already have an old webcam and raspi I'm not using, and they measure exactly what I care about.
Ooh, new requirement!
Set timer on phone when setting timer on machine...
Sorry to hear that. Hope things get better. Don't know if your wife's case fits, but the brain has a lot of plasticity; fingers-crossed.
> my washer and dryer love to lie to me and add 20 minutes to the cycle
We're going to have to assign a business analyst here to capture the full slate of requirements before we start development, i.e., armchair suggestions :-) I don't think agile is working very well here
So like 95% of business school graduates?
They haven't even learned that "less code is better" yet, I wouldn't hold my breathe waiting for them to suddenly learn "more advanced" things like that before they learn the basics.
Feedback is often only considered once something is already on fire (financially, functionally, or literally).
They’re not even selling shovels, they’re selling subscriptions for shovels.
For example, there's also no cabal behind memory prices dropping (ignoring the development of the past months, of course), which in turn enabled web and game developers to use more memory and make their software non-viable on older devices.
> The whole thing dies if it turns into employee scoring
All ICs know this and some management does, but I’m willing to put money that it will 100% become employee scoring.
The Theory of Constraints - AI Era
[0] https://en.wikipedia.org/wiki/Theory_of_constraints
[1] https://www.goodreads.com/book/show/113934.The_Goal
[2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
I would argue that any sufficiently large system reaches a point where more code is in fact the opposite of what it needs.
Nutrition and calories are only useful up-to a point and then we have diminishing and later on negative returns.
Even-tough it is not the best analogy because we are describing two different system, it helps put a mental model around the fact that churning more is often less.
Side Note: A got a feedback from a customer today that while our documentation is complete and very detailed, they find it to be too overwhelming. It turns out having a few bullet points to get the idea across it better than 5 page document. Now it is obvious.
I have absolutely worked on code bases I would describe as "marbleized bricks" where the best thing I can do is carve out the statue they already contain. There's a great satisfaction in making PRs that mostly delete things, but the later result is a program that works faster, has fewer bugs/edge cases, is easier for the next person to debug.
The LLMs certainly can add more layers of marble. Companies don't often know how much more they need an artist with sculpting tools more than a bricklayer.
Tl;dr's, quick references / QuickStarts / cheat sheets and FAQs are also some things they're great at generating.
[0] https://marketoonist.com/2023/03/ai-written-ai-read.html
Finance folks reached out asking if they could vibe code their own app using Copilot/Cursor/Claude for finance planning purpose. And because they know my management freezes whenever there are whispers of "our CFO said so" they even paraded that reasoning - "our CFO "tested" Lovable and he is convinced and asking us to vibe code the app".
If that is not enough they ended with a nicely wrapped reasoning of "we need to try this to be sure that using vibe coded app can exist in enterprise finance with appropriate data security and maintainability".
And mind you this is a reasoning at a company with more than 20+ billion in revenue.
Having worked with these finance apps (Hyperion, Axiom, Workday etc), they're very data heavy and getting good performance out of them requires real engineering, so much so that they come with their own spreadsheet software to handle the multi-dimensional multi-million-row datasets (along with many other requirements like auditability, version control, workflow, consolidation etc) that excel just can't handle with all its limitations.
On the other hand, there's the 'Let Them' theory [1].
[1] https://www.amazon.com/Let-Them-Theory-Life-Changing-Million...
And also, I have been in similar sounding scenarios multiple times. They talk big when everything is going smoothly and nothing is on the line. The day shit hits the fan, they will furiously message me on Teams and insist that I support them in finding out issues. So far it has been about mostly about shitty design choices. This is at whole new level. They want to vibe code an app which will be used to plan and guide company's direction for the next year.
And having less people involved means there is much less communication and alignment.
Not to say it's a panacea.
It would also, I would think, make it easier for the 30% fewer engineers to earn a better living in the long run and reduce human management effort.
This makes the most sense to me. So far AI, being fallible, can only augment humans so you can have less humans to do the same work (or tasks where accuracy can be less than 100%, like lower level support calls/questions). Next comes the task of re-balancing the distribution of labor or teaching other departments to utilize AI.
To me that rings the most true because where AI saves me the most time is in never having a bug that takes more than a few hours to pinpoint, even if I'm looking in the wrong place, because with enough clues the AI will look in the right place before I think of doing so. Like finding a needle in a haystack. It doesn't suddenly make me 100x more productive, but it saves a lot of time on some time consuming tasks.
NO ONE in my meeting was familiar with the title or author.
I felt a little more impending doom upon realizing that.
Surely they were at least aware of the basic premise that adding people doesn’t necessarily speed up delivery?
"Hey we found this bug and-"
"We already found it with Claude, we're still waiting for out next release."
Or worse, its a bug that doesn't exist in prod, since the code keeps changing, and you wont know about the bug until its out there because there's one niche user with a niche use scenario everyone forgot or didn't even know existed, and he's going to somehow crash the entire system with your next deployment.
Organizations "born in AI" appear to buck this trend for obvious reasons (no legacy org. to deal with). My two cents.
SAFe is poison.
Release trains seemed like a mechanical release implementation detail in all cases; not the product or requirement of a given SDLC or process brand.
An Agile Release Train (ART) in SAFe is a long-lived, cross-functional "team of teams" (typically 50–150 people) that plans, commits, and delivers value together on a synchronized, fixed-schedule cadence.
This was a huge motivation behind me trying to design an AI automation platform that comes "batteries included". I also think a lot of orgs, even engineering orgs do not know how to configure basic things like Claude plugin repositories into their installs.
That seems wild, niche/highly specialized field?
Sometimes for good reasons, like thorough validation need or operational constraints like spaced-out maintenance windows.
Sometimes for bad reasons, like a complete absence of unit tests and very old and brittle code bases requiring a lot of manual QA and several iterations for a version to be in a releasable state.
PayPal started greenfield so they baked the qualification and consistency checks into the process and had it automatic. banks ho ooops.
Same for Tesla: they created a hand over free code to (testing) road flow. and they were capable of thinking like that because their roots are software.
GP below confirms traditional finance.
I wonder what adoption is like at older non-tech companies.
The office next to mine is being used to teach a bunch of 20-30 year olds how to be insurance brokers using a powerpoint presentation. Copy paste the presentation into an LLM and you just replaced them all. It feels like... things might be kind of dark in 10-20 years if we just keep barreling down this road.
My dog gets excited and barks to let me know whenever someone is at the door. It might crush his spirit if he knew he is just a useless pet and his contribution is meaningless.
Shipped code can fail. Shipped code can corrupt or delete production data. Shipped code can break your customers trust. Shipped code can lead to literal court cases. Shipped code can force hasty fixes and all nighters.
Some people can afford to yolo their code others can't. Maybe me having programmed for expensive hardware that punches a hole into a brick wall, burns up in a cloud of smoke or hurts people if you make a mistake has to do with the fact that I know.
The LLM won't go to jail for certain things. The one who signed of on the code may.
I kept saying this since Day 1 of llms - even 99% of development reduction means almost nothing in our company in speed of delivery of whole projects. And we are introducing generator of code that semi-randomly has poor performance when they have perf bottlenecks and fills the codebase with... sometimes questionable solutions. Sure, one has to check the results all the time, but then time is spent on code reviews, not much less than actual (way more fulfilling, rewarding and career-boosting) development.
Now I understand there are many more scenarios where gains are more realistic and sometimes huge, but it certainly ain't my current working place. So I use it sparingly to not atrophy my skillset but work estimates are so far the same and nobody questions that.
On code you cannot possibly copyright. Yea they're all on the verge of "Locking in."
Just yesterday I was in a meeting with a customer asking if we could make our FOSS virtualization platform work such that if you yank the root disk out of a server and put it in another one, everything will work with no hiccups. Well, provided it's exactly the same model and you're going to put it on the same network with all the same IP assignments, you've got a shot. I've actually tried to do this before for the hell of it and I only needed to account for the MAC addresses of the NICs being different, as long as you have no other drives and everything else is exactly the same. I'm sure I could whip up something that scans for the predictable interface name and changes the old MAC stored in the NetworkManager configuration files (and wherever else they might happen to be) and change them to the newly discovered one before making a DHCP request, and maybe that will work, but how certain can I really be? I can test on servers I have and I don't have every possible combination of data center equipment all of our customers have. There is no feasible way to test every possibility. Having an LLM whip up the code for me instead of writing it myself doesn't change that.
Ironically enough, that customer is making software for another customer and their own requirement is that it has to run on very hardware on an airplane, which they don't have. So they're working on little NUC clusters in their cubes and at their houses instead, because their company doesn't have extra true server racks for them to use and no budget to acquire them, which probably won't change any time soon given the spike in hardware prices. They're all using AI but what good is it doing? They're spinning their wheels because they're targeting a runtime environment that doesn't exist that they can't test on.
It's a weird folly of the Internet age that the largest companies in the software world are all web companies. Mostly, they're media companies in disguise. Their only real product is human attention and they sell it to advertisers. Tech is just the vehicle that allows them to deliver it. We've valorized their "ship as fast as possible" ethic, which maybe matters, maybe doesn't, but it was never the source of their value. Nobody spends ad money on Facebook and Google because of the quality or delivery speed of their software. It's the human users and data they've captured, which to be clear, software plays a huge role in, but it's not a model all software companies can follow. We don't earn revenue from half braindead doomscrollers wasting most of their day with a background drip of vaguely dopamine-boosting noise blasting into their senses while they leak every fact about their lives to media companies. Our customers have to make intentional decisions to spend money out of finite budgets.
There's another story on the frontpage right now of Coinbase laying off a bunch of its employees and using AI to write more code. Okay, great, but the best that can do is reduce labor expense. They only earn more revenue if consumers decide they want to buy more Crypto and hold it in Coinbase. If Coinbase is using AI to write their software, so is everyone else, so that doesn't give them any kind of edge on quality or shipping speed. Their success is going to be determined overwhelmingly by whether or not people want to buy crypto, a broad market trend completely out of their control. No one in any business ever wants to admit this, but we're all at the mercy of these broader trends.
People are all over this thread citing Ford. Ford didn't decline because they couldn't ship fast enough. They declined because the market stopped wanting what they were making except their full-size pickups, and it's largely just Americans that want that. I don't blame them or think they did anything wrong exactly. People love to do these post-mortems contemplating a world in which someone like Ford accurately predicts every single shift in consumer sentiment that will ever happens and always stays ahead of the curve. It'll never happen. Everything that goes into style eventually goes out of style, and your ability to ship out of style shit faster won't help you.
You said you work for a bank and I'm honestly curious. What causes a customer to choose your bank over another? Do you think it has anything to do with software features? I'm lucky I even got a meeting with the customer I was with yesterday. He told me he loves our product and fought hard for it over a chief architect who wanted something else and made them do a long comparison study to prove our product met their needs better. Why did that chief architect prefer the other product? He plays golf with their CTO.
AI/LLMs aren't innovation the way TCP/IP, linux, or postgres were. To be clear: claude/codex/gemini/grok/whatever exist for profit, to squeeze the last drop of productivity out of you until there's nothing left, and then you're disposable (laid off).
If you like AI, use open source models, use them in your side projects.
2) It's been a hard lesson for me to learn because I'm naturally a contrarian, but you are hired to do what management wants you to do. If you resist, your best bet is to hope they don't notice or care, but it's not going to change much.
If you ran a software company, would you want to train juniors who are slower than AI and much more expensive? Who would just jump ship in two years?
It wouldn't make sense to. "Someone" should do it: someone other than you.
Hiring a mediocre senior is much worse than hiring a grad because they will never get any better, and it's very hard to know at hiring time that they're mediocre.
I’ve only had 1-2 juniors who “didn’t get any better” compared to the scores of senior engineers I wouldn’t trust to anything on their own.
Most juniors with investment from the organization and senior engineers will become competent quickly. That will eventually free up seniors.
Yes, exactly. It's been a problem for a while, and it's worse now.
I'm worried it will go from "it's hard for juniors" to "it's nearly impossible for juniors."
Now of course, you may think you are such a good engineer that companies will kill for you… perhaps that’s true now, but its not true for 90% of the engineers out there. And as the pool of engineers gets reduced, the chances of you being not as good as you thought go up. So the real question is: can you (we all) still make a good living by not using llms. You know support each other and fuck the higher ups? No, we cant. Wwe are full of ourselves, full of elitism (this is HN). We are rational folks, we believe in numbers, in data; we know what we deserve. fuck the rest. The ones who win are the higher ups, of course, not us.
To me, it's pretty simple. I have things to do. This makes it easier for me to do those things. Sometimes that means I can do more things, and sometimes it means I can spend less time on my work, and often both.
I have no idea what the future will hold. But to me, it would be very odd to avoid using extremely useful tools for my current work, because of that uncertainty about the future.
If you're proposing an organized boycott, I would certainly entertain that proposal. But for me, the bar would be high for both certainty that the hypothetical consequences are likely and bad and that the boycott would have a chance of being effective.
At this particular moment, I'm pretty skeptical on both counts. And I'm flatly against the kind of vibes and guilt tripping driven "boycotts" that you're attempting here.
(And I'm way more bullish on the normal legislative and regulatory processes. I think organized boycotts are something to think about if those processes fail.)
Is this a thing? Are there companies out there that don't want to go faster?
There's still an opportunity for engineers to eat their bosses lunch and just start their own company. It's never been easier to start a lower cost competitor.
Employment isn't a social law of nature: it's a transaction of money for "units of work", just like the business might have with other vendors. Governments should be making it easier to become a vendor.
The juniors are eliminated and the seniors indulge in cognitive surrender because it feels good.
Here’s a thought: consider the potentially analogous case of performance-enhancing drugs for athletes. The drugs unambiguously make them better at their jobs, but the drugs have severe long-term health costs and wreak havoc on the fairness of the playing field. It’s easy to see why an athlete might choose not to use them, even when others are.
Of course, those negative factors alone are not enough to dissuade people en masse who want to get a leg up on their competitors, so the use of performance-enhancing drugs must be further restricted by institutional bans.
Business is not like this, because the value of what a business does is in its actual output, not in its entertainment value for spectators.
Of course there are other rules (legislative and regulatory) that apply, for other good reasons. But their goal is not to create an entertaining competitive environment, but rather to control externalities of what companies do.
I favor AI regulation, but I also don't think treating it like a performance enhancing drug would be a smart way to regulate it. Higher business productivity is useful to society in a way that breaking home run records is not.
The revealed preference is very far in the opposite direction at the moment.
Serious question. I think the reason that there's such a disconnect among AI-for-work users about whether it's a panacea or bullshit accelerator is that different software developers have massively different duties and conceptions about what their job is or should be.
2. Figure out what components already exist and what new things we need to build and how things should be integrated.
3. Actually build the things according to what was figured out in the previous step.
4. Review my own work and other people's work.
5. Release things and make sure they work.
6. Respond to emergent issues in things that have been released.
I find the current generation of AI tooling to be very useful for all of these tasks. Less so for task #1 than the others.
What are other people doing that is different?
Anyone remember what SCO did to the industry as it went under?
The part I still don’t get is where Enterprises are dumping internal ‘secrets’ (code, processes, customer needs, internal politics, leadership dreams), into the hands of startups and untrustworthy conglomerates. MS used to be famous for NDA and deal abuse.
I don’t believe for a second the LLM giants would be shy about training on corporate materials and lying about it. And if they start going under? This gold rush might have a long, ugly, tail.
Quite honestly the firings that are happening are the ones who are not adopting the technologies, if you're doing this you're quite literally just putting yourself in scope.
Just read coinbase today. They are culling those who are not adopting the future because they get in the way of progress. They don't help, they don't push things forward and they hold back those who do.
And there is why the hate exists. You as the CEO know nothing about how your business works. You neither actually try to understand nor do you have the technical background to understand. So you substitute gamed numbers. And in doing this, you setup your company to tank the industry that props up the world economy. And then act like you are the rational one while doing this. There is nothing rational about how most CEOs act. There is a reason why companies do better under dev founders than any other circumstance. There is a reason why dev CEOs do better than non-dev CEOs. Yet despite this, you will tank both your company and a substantial part of the industry just so you can get yours. That's why you are getting the hate. Ignorant indifference is just as objectionable as the caricature of a CEO you see in these posts.
My company set up a “prompt of the week” award and brown-bag sessions to help spread adoption. We also have teams meant to develop these workflows. Clearly, they set these events up to play it off as their own productivity. Without a real (read “monetary”) incentive or job security, the risk and cost of spreading the knowledge falls squarely on the developer.
If developers are worried about their jobs with the way the market currently is, they should treat their personal workflows as trade secrets. My example was not specific to AI, but it applies just as much to AI workflows. In a worker's market, it was sometimes fun to share that kind of knowledge with an organization. In an employer's market, they can pay me if they want access to my personal choices.
That sounds like a toxic environment. Sharing those types of things is how I got the recognition to get ahead in my career and I have never once regretted it.
So while it might be nice to say I won't share, boss-man can certainly make it so I must share.
Boss-man actually has a very difficult time turning legal theoretic right into actual deliverables.
But when I've been stuck for a while in a dysfunctional team, I've definitely seen the flip side where other people will find ways to take a lot of credit for minor iterations on my work, where management will reward my productivity with high expectations and high pressure to continue the trajectory they perceive in a single idea, and when the tool becomes a support burden because too many people think it should solve all of their other problems too and I'm now perceived as being the owner of this thing they depend on.
If your only goal is to maintain a performance lead on your peers, you either need to gain and keep an advantage or find ways to actively make your coworkers disadvantaged (or both). And if you're already doing 1) then 2) isn't a far stretch.
> would you like to work on a team full of people like you?
If their team is already like this, what choice do they have? It's a prisoners dilemma where everyone else is defecting and I'm the sole cooperator.
IMO the onus for solving this is on the business owner, either through establishing a knowledge sharing culture or more comprehensive performance evaluation that rewards these innovations.
Nice passive aggressive dig!
I mean, according to your employment agreement, that code is owned by your employer, since you wrote it as an employee for use at work. They could easily demand that you share it, if they knew it existed.
This just illustrates that smart people figure out their own productivity/time-saving shortcuts at work, and little scripts and tools like this are part of it. Happens all the time. Other employees don't, and just plod through whatever manual process they were trained to do.
You have to get used to acting within the grey area and playing politics. Your counterparty (your employer) certainly does. Every businessperson is good at it, or they wouldn't be successful.
In any transactional relationship - which employment is - when you want to do something, don't think: I can't do this because they wouldn't like it. Instead think: what are the likely consequences of doing this? Are they positive or negative for me, on net?
And I'm not a "at work we're a family!" guy, but I wish we could just be excellent at our jobs and share it with each other without worrying if I'm digging my own grave.
If your employer is expecting that you selflessly share your time for free, you’re getting fucked. Most people are paid to do their job. They are, of course, then expected to work for their employers while on the clock.
What I find strange about this is that in 2020 nobody would be this openly cynical and selfish about, say, good Python idioms, a useful emacs configuration, git shortcuts, etc. This attitude of "your job is to deliver value for the customer, anything else is a distraction, and if you share your hard-earned value-delivery techniques with others then you are a sucker" - this is new, and very disconcerting.
I understand there's not much we can do to stop the cyberpunk dystopia, but do we have to leap in head-first?
I definitely saw people have concerns about vimrc files and their personal library of shell scripts well before 2020, and I've seen people early in their career get burned by sharing it too. They had a tool that made them productive, it got out of their hands, and suddenly they're getting negative feedback from someone who tried using it and it didn't meet their expectations, or it got checked into the repository and now the script they used at their last job too has their current job's copyright notice and license on it, and they're perceived as being petty for trying to claw back their own intellectual property because they didn't go to the trouble of slapping legalese all over their personal tools.
If your employer is extremely spiteful, they might burn a pile of cash to hurt you. But that's not normal.
>it got checked into the repository and now the script they used at their last job too has their current job's copyright notice and license on it, and they're perceived as being petty for trying to claw back their own intellectual property
Where someone is causing a fuss trying to claim ownership of something they never actually owned and thinking the other people are the ones being unreasonable.
This mindset has always existed in the area we're talking about, and not because it's sharing something to speed up with. It's because we don't want to get stuck doing a second job supporting the tool.
I've built all sorts of random tools for myself over the years and haven't shared a single thing, but share the tips and tricks like your examples all the time.
If they gave immediate raises or bonuses for stuff like this, then things would change.
None of it is actually that crazy that everyone else could think up.
What I've noticed in my own experience here is that even when I do share my own prompts/skills few people use them (or alternatively they were so basic that everyone already had their own version).
e.g. If someone doesn't care about xyz before AI, they probably won't after AI even if I serve them it on a silver platter.
Does that person rationally go find more work to take on with that reclaimed time? Probably not unless it's their company or exceptional motivating circumstances exist.
yet I don't see anyone question whether management will be just as excited to see that less work is needed and that it'd just result in layoffs
Contrast to remote work where the benefit was extended to all regardless of performance, thus becoming a large target for management to cut.
I think the talk about management & capital demanding ROI will be the inflection point to watch, as a downstream effect could be AI haves & have-nots, depending on open weight models' competitiveness and local capability relative to the SOTA models.
At what point is inspiration and thought just devalued and worthless in the name of doing things instantly. The work has no soul.
It really comes into its own when you treat it as a tool that can build other tools. For example, having it build tools that force it to keep going until its work reaches a certain quality, or runs compliance checks on its outputs and tells it where it needs to fix things. Then and only then, can you trust its work.
Right now most current roles & workflows are designed around wrangling the tools you’re given to do a certain job. In that regime AI can only slide in at the edges.
In the old model, performance and OKRs were anchored in disciplines, job titles, and role-specific expectations. In the AI era, those boundaries are starting to collapse. The deeper issue is psychological and organizational: people are constantly negotiating the line between “this is my job” and “this is not my responsibility.”
That creates a key adoption problem: what is the upside of being visibly recognized as an expert AI user? If people learn that I can do faster, better, and more cross-functional work, why would I reveal that unless the company also creates a clear system for recognition, compensation, or career growth?
There's a mistaken assumption under there that businesses can identify who that statement describes.
Some can. But a lot of businesses cannot identify and reward, or support, or just not RIF, those people. Like a lot a lot. More than I'm comfortable lumping under statements like "well those are just bad places to work/places that should be shut down".
There's no punchline or counterproposal there; that's just my observation.
Take Andrej Karpathy as an example. Even if I knew exactly what tools he uses and what his workflow looks like, I still would not be able to produce anything close to what he can produce in a few weeks. And he is not standing still either—he is evolving at the same time.
A lot of real expertise is not in the visible/system-able workflow. It is in someone’s experience, taste, judgment, and wisdom. You can copy the artifact, but you cannot easily copy the thinking behind it: the principles, the decision-making, and the ability to apply those principles across many different/subtle situations.
But I do agree with the concern behind the argument. People may worry that sharing what they know could weaken their own position. And the more uncomfortable question is about peers: if someone’s role can be “retired” because others absorbed their knowledge and skills, then it is hard not to ask, “Am I next?”
We are definitely struggling with the same issues author describes, but even worse the leaders down at the Crowd level have some perverse need to achieve reuse across their teams, rather than letting their Crowd experiment. One team does something interesting, we must stop and get that thing out to all teams in that group, so everyone “benefits”. This is a scarcity mindset, which made sense pre-AI where code was costly and ideas were more valuable.
At the same time, everyone not only has to do their work, they need to be 25% more efficient from AI (new KPIs), and so their own learnings slow to a halt, and the team with the cool idea has to give presentations instead of hacking.
The CEO has a youtube style platinum token plaque for their office.
The bias in the assumptions here is absolutely bonkers.
Problem: GenAI is not generating any visible return on investment.
"Solution": rearrange your entire development organization around the technology and start inventing new tooling.
What's entirely obvious is that the point of such articles is not the stuff they purportedly discuss, but the normalization of assumptions those discussions are based on.
But the internet was a simpler concept for businesses. Basically it was you can now sell to people from their computers. AI’s promise is what? It can approximate reasoning about things? This is much more challenging implementation puzzle to truly solve.
I don’t know that I’ve seen anything of real substance outside coding tasks yet.
I propose employees create self-training byproducts as a result of any AI interaction. And then they also work with their Cuban manager to make sure that these self-training byproducts are a part of their growth plan. This can guarantee growth without losing that opportunity To interact with the intelligent AI system (on topics that are relevant to the company's short, mid, and long-term strategic advantage,).
While I do believe higher developer productivity can lead to faster reacting to market forces or more A/B testing, that won't necessarily lead to a successful business. Because ultimately it rarely is the software that's the issue there.
Debugging and developing first fixes is also one of the spaces where current LLMs are the biggest force multipliers. Especially if you have reproduction cases the LLM can test on its own
But long-term it might look very different as more and more of the code becomes LLM written
It already has; ship has sailed.
https://blog.pragmaticengineer.com/the-pulse-tokenmaxxing-as...
I'm staunchly pro-AI as a technology, but I do think the bubble is going to pop in the next year or two just because the business value won't materialize for most companies fast enough.
AI content has a look and feel people sense immediately.
It’s amazing to see how quickly things shifted from “wow this is so cool, AI is going to change everything” to folks calling out “you lazy bum, this just looks like some slop you threw together with AI… let’s get some real thinking please.”
We are firmly heading into “trough of disillusionment” territory on the hype cycle.
Can we get some enabling legislation? A UN resolution perhaps?
The “get an immediate agent answer then a human expert’s fast-follow” is I think a great idea for many domains - imagine if you could get legal advice this way; the agent will have already explained the basics and the human expert just has to provide corrections - way less typing by humans.
Also, the corrections are now documented and could become future grounding for the agent.
They won't just need to understand what problem the requestor has (or thinks they have) but also validate that the "immediate" feedback wasn't subtly horribly wrong.
So, like what already happens when my boss asks claude something and I have to pick up the pieces. Except now it's everything he slops about the topic, not just the ones we discuss later?
> a great idea for many domains
I completely agree. This is a great idea. If you don't do something with it I'm stealing it. ;-)
The more I use AI, the more I see mistakes. I've noticed others see these same mistakes, correct them, then when queried say "Oh, it gets it right all of the time!". No, having to point out "you got this wrong, re-write that last bit" isn't "getting it right". And it's not that the code is wrong overtly, it's subtle. Not using a function correctly, not passing something through it should (and the default happens to just work -- during testing), and more. LLMs are great at subtle bugs.
So moving forward with this isolation you mention, ensures that maybe the guy in the company, the 'answer guy' about a thing, never actually appears. Maybe, he doesn't even get to know his own code well enough to be the answer guy.
And so when an LLM writes a weird routine, instead of being able to say "No, re-write that last bit", you'll have to shrug and say "the code looks fine, right?", because you, and the answer guy, if he exists, don't know the code well enough to see the subtle mistakes.
AI can get a pretty good picture, near instantly, whenever you need it.
It’s not just competent-sounding, it is reasonably competent, and certainly very useful for tasks like that.
Gone are the days of mandatory corporate "synergy" and after-work bar gatherings to promote "team building."
AI is showing people in the tech industry that they're just interchangeable cogs. AI is bringing the offshored Indian work environment to Silicon Valley.
> I do not want to make this a cost panic story, that would be the least interesting way to think about “rented intelligence”. The question is not how to minimize token spend in the abstract, any more than the question of software delivery was ever how to minimize keystrokes.
If tokens were as cheap as keystrokes -that is, effectively free- then "How do we minimize token spend?" wouldn't be a question that anyone asks. It's because keystrokes are effectively free that you only ask "How do we minimize the number of keys pressed during the software development process?" if you're looking for an entertaining weekend project. If keystrokes cost as much per unit of work done as the -currently heavily subsidized- cost of tokens from OpenAI and Anthropic, you'd see a lot of focus on golfing everything under the sun all the damn time.
Our mental models of developments like the industrial revolution, literacy, printing or suchlike tend to be a lot more straightforward than how things play out in practice.
When a bottleneck is eliminated... you tend to shortly find the next bottleneck.
Meanwhile, there is an underlying assumption everyone seems to make that "more software, more value" is the basic reality. But... I'm skeptical.
To do lists, wishlists, buglists and road maps may be full of stuff but...
Visa or Salesforce have already exploited all their immediate "more software, more money" opportunities.
The ones in a position to easily leverage AI are upstarts. They're starting with nothing. No code. No features. No software. With Ai, presumably, they can produce more software and make value.
Also... I think overextended market rationalism leads people to see everything as an industrial revolution...which irl is much more of an exception.
The networked personal computing revokution put a pc one every desk. It digitized everything. Do we have way better administration for less cost? Not really. Most administrations have grown.
Did law fundamentally change dues to dugital efficiency? No. Not really.
If you work on a terrible enterprise codebase... it's very possible that software quality/quantity isn't actually that important to your organization.
It's possible capitalism will drive all enterprise to terrible codebases.
While AI tools have been provided pretty quickly (over a year ago, I initially used gemini cli, then copilot once it added anthropic models) the management is absolutely clueless about it.
The top wants agents. Every team is asked few times a week "what autonomous agents will you build next" and answers the current AI lacks agency required not to mess up critical long running tasks and generate even more work are falling on deaf ears.
(also ideas such as, why don't we setup a wiki page were teams can post their repetitive tasks and we can use AI to script them, are considered "not fast enough" - just build it... but we are the automation team, we automated everything we do years ago :-)
Middle managers on the other hand suddenly started giving juniors senior's work and asking seniors "tell them (juniors) how to prompt it".
Seriously? How about I prompt it myself instead? Oh, but it makes a shit load of architectural errors and boobie traps the junior will fail to find... So now instead of a cursory glance I have to spend an hour reviewing a small PR from them.
And any questions about "why are you creating a new X for this instead of extending the existing one?" are met with blank panicked stares...
The essence of this BS is contained in my description of the recent "Copilot Review" incident.
We sometimes merge the same Github workflow files (10 line files) to dozens of repos, we have to obtain approvals for the PRs from a bunch of teams working in different timezones, but the merge has to be done everywhere at once and it has to be coordinated with other work.
As we were on a day of such task some "helpful hand" enabled Copilot PR reviews for the whole org.
Copilot helpfully opened 7 or 8 discussions on each PR giving us such precious advice as "your concurrency group uses the commit sha as a differentiating factor, this will allow multiple runs to proceed concurrently" to which one is tempted to answer "no shit sherlock".
We suddenly had almost 200 conversations to "resolve" an hour before the merge and a bunch of approvers didn't give their approvals because "there is a discussion".
Thankfully we had copilot that wrote us a script in 5 minutes to resolve the problem caused by itself...
Maybe our next overnight agent can go over all our open PRs and close Copilot Review conversations with appropriate messages?
This is just sales copy for various AI companies, laundered through an "influencer". It might as well be the CIA sending their article to be published in Daily Post Nigeria, so that the NYT can quote it as "sources".
The title is just clickbait. The rest of the content are fluffy bunnies and rainbows. It's all summed up as "continue to consume product, but remember to also do X". Sales copy + HBR MBA bait.
The closest thing to an honest, less-than-rosy example is the "junior person" who has no idea about the code they committed.
What about the "senior person" who has no idea about the code they committed? What about the CISO who doesn't understand that pasting proprietary documents willy nilly into the LLM's gaping maw might have legal/security/common sense implications, and that it is his job to set policy on such behavior? What about the middle manager who doesn't even try to retain the most experienced dev in the company because "we don't need the headcount anymore, now that Claude is so fast"? What about the company eating its own seed corn because every single junior position has been eliminated and there are no plans for the future anymore? What about the filesystem developer who fell in love with his chatbot girlfriend and is crashing out on Discord?
Oh wait, scratch that last one. He left the company and is crashing out on his own.
Carry on, then.
Fear not: he has a place to feel welcome and included!
https://www.newsweek.com/inside-world-first-ai-dating-cafe-1...
Not a problem if the hired "AI" now does that job. /i