In my large enterprise world, AI adoption hasn't made it outside of the development teams - only developers have access to Github Copilot.
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.
> 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.
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.
Exactly. It's just that they mix up the steps. The last step, the assembly, is highly automated and usually very fast in software production, since it is done by a compiler (and the aptly named, assembler). The people involved are doing engineering and design, which is much harder to control.
Atleast 90% of the time whenever someone mentions Ford it is to spew out Ford PR garbage they once heard that they took as real history instead of the marketing it really is. It really should be held up as an example of how powerful well designed PR is and the myths it generates.
It's not true at all. In software, the factory line is nothing but cp or httpd and neither costs nor produces any value. In cars, the factory line both costs and produces all the value.
> the factory line both costs and produces all the value.
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.
> In software, the factory line is nothing but cp or httpd
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.
Really? So all the designers and engineers at Ford who don't have an iota of a car built by the time they're done with their work aren't producing any value?
The design is like the electricity to the factory. You need it or else you get no cars at all, but it's a small percentage of the total resources consumed and produces no value at all directly.
I'm a manager and the VPs are starting to ask - how many story points are we getting with AI now. Now we do story points = number of days to implement. (I know this is not real agile but just assume you are in the same position)
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.
When management starts tracking improvements in story point productivity then the agile teams inflate their story point estimates. Sometimes this involves splitting user stories in ways that don't really make sense from a customer perspective just for the sake of having a place to tack on more points.
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.
A few years ago I was on a massive project to rebuild and redesign a major public facing portal. Our dev team was nails, cranking out features and components on a very tight time table. Several other teams were inflating their story point estimates so when the higher ups would get their weekly reports, our team was always in dead last for completing story points.
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.
No one's ever been able to explain story points to me without saying something like "Story points are kind of like how long it will take to implement, except it's not that".
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.
IANAScrumlord, but ideally story points are like a foreign currency: It's both normal and healthy for exchange rates to constantly fluctuate, and every country (team) has it's own units for capturing guesswork and confidence and quality/speed mix.
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 once met someone who refused to engage with leadership using his team's story points as a direct measure of productivity. To make it harder to extract the data and compare against other teams, they moved to using names of animals to represent types of task associated with differing amounts of uncertainty.
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.
I always see SP a combination of time and risk. I think a lot of people do not include risk in the estimate.
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.
I've always asked for it when joining a team to calibrate my story point estimates. At some teams 1 point is about a half hour task and at other teams it's a full day.
Almost certainly. Software firms are pretty bad at self-evaluation and they're profitable enough that Capitalism won't force them to do it either.
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.
It's worse than that. Developers themselves are drunk. They'll be cut off from tools right when they no longer understand the underlying code they're responsible for.
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.
Amen. We are still running highly unoptimized workflows in AWS and nobody reviews why we spend so much $ on that now while it was peanuts when we did it all ourself.
> They're not going to dredge up decade old institutional knowledge
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.
> 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, 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.
Precisely, cars are more-or-less identical copies, at each position along the assembly line its just one of a handful of variants of the step that needs to be executed.
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.
An assembly line is plumbing too. And just like software, while there are a finite number of variants at any specific time, the plumbing is constantly being rearranged for various reasons. A line won't look the same in 6 months as it does today.
Physicists, engineers, scientists, ... they have much more complicated tasks compared to plumbers, programmers and code monkeys.
I've sat next to the industrial engineers designing the lines and MechEs working in CAD. My software job wasn't all that different at a high level. We all wrote requirements, made bugfixes, and complained about the tier 1s. They usually spent more time visiting the lines in Asia/Mexico/Michigan/Canada. I just emailed the factory when I needed to fix something.
> 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.
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).
The plumber who has a robot who can make perfectly measured custom one-off tools and specially constructed piping runs inside your walls is going to have super powers compared to somebody who has to go to home depot and assemble a bunch of PVC pipes or whatever.
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.
> 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.
The machines all beep when they're done.
A baby monitor in the machine area will accomplish the same thing :-)
Have you considered taping a sensor to the light, or measuring the electrical current flowing through the power cord? Both should be a bit more reliable. The idea of messing with mains power is scary at first but with basic precautions it's fine, and I think you can buy current meters with various interfaces if you aren't comfortable.
Why would I buy power meters and mess around with indirect signals that don't measure what I want (how much time is left on the cycle) and instead just tell me whether it's running?
I already have an old webcam and raspi I'm not using, and they measure exactly what I care about.
Ah, but my washer and dryer love to lie to me and add 20 minutes to the cycle because they're "eco-friendly". And this is mostly to help my wife who has a brain injury and can't remember to set a timer.
> Large enterprises need to learn how to ship software faster
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.
Exactly. Everyone keeps talking about how much velocity they have with AI but no ones talking about quality for bugs that come from it. Just how fast they can ship.
More code means more support and more maintenance. If your team is already overloaded or if it's going to be reduced because of AI, things are going to get tough.
My bigger concern is actually that, if a company isn't careful, the bloat (complexity, amount of code, other artifacts etc.) will just balloon and largely cancel out any gains.
Feedback is often only considered once something is already on fire (financially, functionally, or literally).
That’s the game plan for the AI companies: once companies have massive codebases of critical AI generated code and a skeleton crew of prompt engineers they’re going to be locked in to the AI product to develop anything new.
They’re not even selling shovels, they’re selling subscriptions for shovels.
I don't think there needs to be any intentional evil scheme for this dynamic to be worth considering and mitigating.
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.
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 would argue that any sufficiently large system reaches a point where more code is in fact the opposite of what it needs.
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.
Like in that comic strip[0], where one side uses AI to inflate his bullet points to make it look better and have more content in the email, then other side uses AI to summarize it to bullet points.
This happens a probably a billion times a day. I shudder to think of the cost of it. Especially after knowing how LLMs aren't great at summarizing nor are they flawless at expanding information
My larger enterprise world today AI adoption seems to have taken a turn for the worse.
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.
> Finance folks reached out asking if they could vibe code their own app using Copilot/Cursor/Claude for finance planning purpose.
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].
Because the next email is going to be "we demoed the app to our CEO and he loved it and he wants it in production". I have never seen the team back down from their ideas.
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.
I think it’s fairly normal at least in my career - rush to ship something, lots of “we’ll polish this later,” two years go by, get called into vp/cto/whoever’s office when the debt comes calling like “what the fuck why is this like this???” and I have to say “that ‘later’ we decided is now I guess”
The script I have fairly seen being played is where the one doing MVP gets rewarded and moves on with a promotion. The weight of completing and stabilizing the MVP falls on some one else who is not vocal enough in terms of influence. Ironically the flashy MVP does not includes monitoring, logging, security, edge-cases, CI-CD, DR, scaling which is why vibe coding is getting so popular and everyone seems to be under the impression that engineers are not needed anymore.
Run for the hills. These sorts of businesses can get by with an old dos app running in an emulator to manage sales and inventory. They don’t care about maintainability or anything we care about. If it works it works and they will squeeze it to work as long as they possibly can. Which could very well be three decades or more.
That's an interesting take I don't see anyone else bringing up.
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.
The debugging improvements have been huge for me too. I was debugging some financial software, and while it took a few shots, just with access to my code and not to the database that showed the issue, it found a fairly complex problem.
"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.
I asked who hadn’t read that in an engineering meeting recently. No one had heard of it. Now, I have been in tech for my entire life. That book was given to me in 1993 as I was just starting out in college.
NO ONE in my meeting was familiar with the title or author.
I felt a little more impending doom upon realizing that.
We have a "two timelines" approach going on and I'm curious if others are seeing the same. There are official "Engineering-supported" services. There development speed is not the bottleneck. Engineers demand clean requirements that take forever to show up. Testing and deployment scheduling also take forever post-development. Important people are so fed-up that they've started hiring people to vibe code and develop services without going through Engineering. Code is shipped much faster here but technical debt accumulates rapidly. The important people are beginning to hire Data Scientists who sit outside of the Tech org to manage the AI code. It's all very interesting.
Sounds like your company has bad or missing business analysts and/or product owners. Someone's supposed to be working between the stakeholders and engineering to develop those requirements and commit resources for testing. These "important people" are re-inventing the wheel and will be mired just as bad or worse until they figure this out.
I agree with you in general. And have a good chuckle when the vibe coders get derailed by some roadblock that would've been obvious to a professional engineer. But it's a bit one-sided to say that we have bad or missing analysts and product. Even good product can't keep up with how fast AI allows you to go. At an established company, maybe you shouldn't go as fast as AI allows you to go, but try telling that to the "important people."
What do release trains have to do with SAFe? I've worked in a few places that have the notion of a release train (roughly a mutex for "changes being shipped and a burn-in window afterwards" plus some optional batching of changes based on risk level or urgency). Only one of them even gave lip service to SAFe; others had different methodologies/levels of devops for releases/"Agile"-ness (whatever that means).
Release trains seemed like a mechanical release implementation detail in all cases; not the product or requirement of a given SDLC or process brand.
Same here, but instead of the developers having access to Github Copilot, some selected few devs have access to some internal proxy, that goes to Amazon bedrock, where we have "400 request" per week to Claude Sonet :))))
Its trickling in slowly to non dev teams. Im consulting with a large fin-tech on Enterprise-wide AI adoption at the moment, and I'm seeing the same parallels though: you have power users that reap disproportionate rewards from it, and then you have the "tab complete" crowd that copy paste things into the prompt.
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.
Meanwhile in private equity world, they have realized that code is "piling up from 10Xing everyone's performance" and as a result they have solved it by just firing all QA, focusing only on speed to prod, killing signoffs, and scheduling and code review. We are probably going to bankrupt ourselves from an idiotic mistake somewhere here. But nobody will ever know until it happens. Don't take those gates for granted.
probably software of old where bugs are expensive, thus a thorough process was created, V model with consistency reviews; add manual hand overs and subsystem tests and you easily get months to production release.
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.
It's good to know your experience mirrors mine. Developers are moving faster, but the rest of the organization is holding them back because processes and decisions still rely on other parts of the org. Has anyone else observed the same?
Organizations "born in AI" appear to buck this trend for obvious reasons (no legacy org. to deal with). My two cents.
I'd say there's bottlenecks within the developer processes without even considering org processes. Code review, release, post release ceremonies. Feels like they absorb much of the gained productivity in the coding phase.
Especially when it waits a month and all the effort is either irrelevant or incompatible with latest changes that finally got through. So much token wastage to top off the recent chaos. Hopefully it improves just as fast as it materialised.
Unshipped code can't break. How is it a liability and not an asset? The money maker is making money and the changes that potentially would interfere with that are held up at the gate. Seems like a good thing from a business perspective.
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.
A lot of Bullshit Jobs[1] are going to be replaced by AI - it's not clear whether these "brokers" who can be trained with a powerpoint presentation are actually doing anything useful for society or even for the economy.
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.
I don't know who needs to hear this, but: shipped code ia a liability too.
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.
There are so many elements to this. I've worked in nearly every part of software orgs. Development, ops, professional services, pre-sales. There are bottlenecks everywhere. Faster shipping gets you nothing if your customers procurement budgets don't increase and they're not buying anything. You can wow new customers and lure them in with shit you get out the door super quick that appears to work but falls flat after six months of usage, but you damage your reputation in the long run. So how do you guarantee your software will actually work after six months of usage? You have to test it by running it yourself for six months. There is no other way. No automated suite can exercise every single possible customer use case over a long period of time. It's a combinatorial problem.
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.
> using TDD [...] without focusing on your core product
This. Even in large enterprises, I've seen projects prioritize code metrics over product metrics. A beautiful codebase that nobody uses is completely wasted effort.
In my experience, the level of test coverage has little to no correlation to the quality and readability of the codebase.
These are subjective, of course, but some of the easiest codebases to understand had low test coverage, and some of the most complex codebases had high test coverage. The opposite has also been true.
> it (TDD) makes you feel like a good programmer even if none of it necessarily contributes to the results your team is supposed to achieve.
It also, in my experience, often makes refactoring difficult because the implementation is set in stone, not the behaviour. I know the TDDers say this is because the tests are bad but, like agile, very few people seem to be able to "do it right".
> All of the really hard problems are not solved by TDD.
I've never seen TDD iterate towards good architecture. It optimizes for testable logic.
> A coding agent permits one to feel as if they have the raw productive power a great programmer can tap into. [...] Those cathedrals are not the great works they appear to be. The construction is shoddy and the architecture nonsensical
In other words, AI allows junior/mediocre devs to _feel_ experienced and produce naive implementations much faster, burying the experienced devs in the drudgery of code reviews and defect triage.
Missing the /s? Most people have a calculator in their pocket all the time now.
I remember having to split bar tabs by hand at the end of the night without a calculator. The waiter delivers a hand-written bill, and we'd calculate how much each person owed, splitting drinks individually and food equally, recalculating tax and tip to derive each person's total. We'd pool the cash in the middle of the table (with people taking their own change as they go where possible), then counting all the cash and making sure it still included sufficient tip. All after many pints. I do NOT miss those days.
Guns N' Roses blazed this trail in 1986 with their faux live EP titled Live ?!@ Like a Suicide [0] which was reissued as the B-side to G N' R Lies in 1988.
> Take away the agent, and Bob is still a first-year student who hasn't started yet. The year happened around him but not inside him. He shipped a product, but he didn't learn a trade.
We're minting an entire generation of people completely dependent on VC funding. What happens if/when the AI companies fail to find a path to profitability and the VC funding dries up?
What will happen is pretty obvious. Those companies will either be classified as too important to fail and get government support or go bankrupt and will be bought for pennies on the dollar. For the customers nothing much will change since tokens are getting cheaper every year and the business is already pretty profitable. Progress will slow down massively till local open weight models catch up to pre-crash SotA and go on from there.
ChatGPT 3.5 came out coming on 4 years ago now. I don't think a human generation (~20-30 years) needs to be the benchmark here, but new juniors in the industry for a handful of years can be said to be a whole "generation". That how I was reading OP.
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.
reply