There is no description of what the thing is, no indication of what value it provides its users. The closest it gets is "the product has been used by hundreds of users internally, including daily internal power users".
But the fact that the thing has a million lines of code is repeated twice in the first few hundred words.
My guess is it’s an email filter.
> million lines of code
> written 100% by agents
Yeah, probably an email filter. Or maybe a JS menu for a departmental wiki that basically recreates jquery using MS JScript and transpiles it into JS 5.
It may also be an email generator.
The email filter team is trying to match the pace of innovation of the email generation team. At stakes is the ability for the employees to process the billions of mission-critical generated emails each of them receives each day.
Probably because you smoked too much weed in school.
Remember, this is the tech industry! An abject lack of knowledge is no impediment for people with boundless confidence in their assumptions!
There are certainly very large applications in that repo in the hundreds of millions of lines of code. But comparing the entire repo to single applications is not an apt comparison.
The world’s biggest software is usually built over endless adapters of different data and a need to reconcile endless edge cases with laws, regulations and real world complexities.
https://openhub.net/p/chrome/analyses/latest/languages_summa...
Somehow everything boris says has become the word of God. The dude is just an engineer, like you and me, who gets unlimited tokens for free.
And this is hacker news. A place where famously the most upvoted comment is the one critical of the post.
I may not be representative of the universe or have a controlled, randomized study to back it up, but that's not what upvotes are for are they?
I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down. More pragmatic and realistic takes are seemingly shared more openly, and are maybe even getting through to top leadership at some tech companies. Maybe not all is lost yet.
“Technical debt” never hooked management in the same way and we have found it hard to convince them that it needs to be addressed. Debt in general is something that can be a problem, but doesn’t need to be avoided or addressed until it is a problem so the can is kicked down the road.
To me, tech debt, captures the idea that we cut corners now to move faster, with the understanding that it will need to be "re-paid" and cleaned up later, otherwise we take on too much tech debt, and everyone knows too much debt is bad...
AI slop code means people feed their tasks to a model, trust it to drive the changes, they might do some cosmetic clean ups, then generate a 3 pager PR description they didn't even read themselves, then toss it over to the code reviewer, let that chump figure out what the hell I was doing while I ship 3-4 more PRs...
AI slop is an easier concept to quantify. It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.
Its connotation also includes being vastly larger than needed for the purpose it serves, _if_ there is even any purpose.
Seemingly engineers get this wrong too. I'm reminded of when Cursor bragged about how many lines of code a group of agents could produce, with the underwhelming results of a barely working browser, when the same could be built with much less code.
But they highlighted the amount of code as they were proud over how much slop their constellation of agents had shit out, and these were supposedly engineers, really strange to see.
And anyway, I’m pretty sure what people really mean by this “less is better” mantra is: the lowest amount of code that still accomplishes the goal and is still readable is preferred. Linux apparently has 40M lines of code, and I bet most of it is better than mine. Some things just take lots of code.
Which seems to leave room for these agent salesmen to pitch SLoC as a plus. We just have to believe those lines are all good ones. I that case, it would be impressive. I don’t believe it, but they are probably pitching to people who do.
No, it's the perspective of a programmer who wants the project to not be bogged down too much in technical debt so every change gets slower and slower to implement, as everything gets more intermingled. A clean design helps you move faster for a long time, compared to a design that is fast to implement but makes it hard to move forward properly in the future, without resorting to shortcuts and/or hacks.
> Some things just take lots of code.
True. Rich Hickey does a good job differentiating between what's complicated because the domain is complicated, VS what's complicated because the implementation just ended up that way, even though with some more thought and design, could have been made a lot simpler.
I think it is (or should be) a goal & business-oriented concern as well, not just an engineer's who enjoys their craft.
More complex systems are worse than simpler systems (that accomplish the same), in cost, maintenance, fragility, ease of understanding, etc. Fewer moving parts usually result in higher reliability, fewer things that can break down or fail to interact properly, etc. That's a business concern too, not just engineering craftmanship or whatever. Business people should care about this too.
I don't think this is the same as bikeshedding over irrelevant details, something we software engineers are often prone to. Monstrous complexity does impact the business!
I wish I were joking.
(The had never been an engineer.)
(I once worked with an engineer that had two PRs, both fairly small bug fixes, in a given calendar year, and when I looked more carefully, they did not have any other obvious output or impact.)
You're saying that the manager-of-managers would argue that the number of PRs should affect perf ratings? Or the MoM would push back against the line managers who were giving ratings based on # of PRs?
I wonder if a small part of this is more and more business and product people actually trying to incorporate AI into their daily workflows. I have seen this in both small companies I work for. People were very excited about getting Claude Cowork a couple of months ago, and while they use it daily, I would say they are rather underwhelmed compared to the magic they were expecting. Complaints include the output being mediocre and verbose, it getting the most basic things wrong, hitting token limits all the time, and people going back to doing things themselves because it is faster.
Sure, there is some degree of holding it wrong in the beginning, but people are realizing that maybe, just maybe, there is still somewhat of a gap between what AI CEOs, LinkedIn grifters, and YouTube AI supplement peddlers claim and reality.
Did those engineers not actually read the complete tweet? Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work". Which doesn't seem like satire at all..? It just means "develop mostly reliable AI-driven refactoring tools with good guard rails". Which seems quite sensible, actually?
Making a grand claim of a goal and not really having an explanation on how to achieve it isn't really much better. I could say "we want to scale food production so that one farmer could manage a million acres of corn a month", but that wouldn't really be sensible. A line of code is less work than an acre of corn of course, but I don't think it's at all apparent what upper bound for how much code is actually plausible for a single engineer to generate in a month and have any degree of confidence in. Given the absurd levels of hype around AI from non-engineering management in the past couple of years, it's not clear why the benefit of the doubt is earned here when there legitimate are managers and executives claiming pretty much exactly what you're claiming this guy wasn't.
Porting to a new language is easy, but does nothing useful. What we need is to fix the mistakes of the past so we can get to the future. We need to make acceptable performance.
> Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work"
These are one and the same. Whether it's ported code or not doesn't change that. The framing device also doesn't matter, because it's the exact "Oh it's our goal" shtick that executives use in the former's case.
"It's just a measure" doesn't cut it in a world where every single AI measure immediately gets turned into a target by executives greedy for efficiencies that don't exist.
EDIT:
Right, I forgot. This is HN where everyone is a galaxybrain and "Port a million lines of code per month" is a totally reasonable goal for a single individual.
In contrast, converting 1M LOC of code per month is a much more solid measure, as long as you measure LOC of the source, not the new code. Sure, in the short term you can pick the easy/verbose things to port, but it's hard to do sustainably. A 5M LOC code base would still be expected to be ported in 5 engineer months.
Granted, you can still rush the work, not test properly, neglect good planning and engineering. Ported lines of code should not be the only measure (just like with any other measure). But it's a much less problematic measure than coding 1M LOC
Which is the core point of my reply and not something to just be casually handwaved, thank you very much.
Otherwise it really sounds like a recipe for unnecessary huge risk with dubious expected positive outcome.
Not saying don’t have fun, but on the other side maybe not with the core product of you cash cow already?
Because many programmers don't believe that'd work. See the reaction to Bun's porting to rust. (I bet Bun will work and prove those programmers wrong, but that's another story.)
The marketing ploys of OpenAI/Anthropic where agents build something that nobody uses might be hard to track given that there are zero users. But what about everyone using agents for real software? It's trivial to prove that agents make progress.
Why? If you can deliver the same thing in fewer correct lines of code wouldn't that be preferable? At a bare minimum if you're still insisting on using AI to slop out your project, having it do things in fewer lines of code means you can fit more into your LLM's context window.
it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.
Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?
You're arguing the inverse: that at least some parts of the code are independent of N. Sure. But the topic is the part that isn't.
Moreover, writing too terse code harms readability and maintainability. There is such a thing as irreducible complexity.
Because they're bullshitting and using AI as an excuse to correct from their covid era over-hiring while simultaneously making themselves look good to investors by showing they're embracing the hip new technologies to become a more streamlined and cost-efficient operation than ever.
The reasons we rejected LoC and other measurements have not changed (broadly: code output isn't important, quality output is). AI has all the same problems people do. But for whatever reason we are throwing what we've learnt away. It's kind of embarrassing.
In addition to "feel productive", two other feels I think are flying under the radar:
1. You get a parasocial relationship with a "friend" (or at least conversation partner) who seems to "understand" you.
2. You get some form of gambling entertainment when you pull the lever and the output keeps landing on different sides of the jackpot you want.
While #2 has some overlap with classic creative struggle, I think it can at least be seen as a kind of junk-food verson, where the frequency is different and the health-promoting parts aren't present.
That's because you would always have loosely involved but aggressive and demanding bosses (there is unfortunately an economic value to the boss whose primary task is forcing more effort out of the employee and who doesn't help coordination or anything else). So at best you had two intersecting clouds of approaches with actual accomplishment intersecting with LoC and related measurements.
The thing AI is that it provides all the tools to satisfy that loosely involved but demanding boss. So suddenly you are going to have a larger demographic of people who like LoC and feature-additions as metrics 'cause now they are easy.
It is weird that the author seems to understand that the pro-AI claims made by AI companies about the product’s necessity are not falsifiable, but then backtracks with “woah woah woah but don’t think I’m anti-AI.”
How is the assertion above any more rigorous than the productivity claims the author is criticizing throughout the rest of the article? That you won’t “survive” if you don’t adopt AI within a few months?
It is not true when the AI CEO says it, and it is not true when the person calling BS on the AI CEO… for some reason also says it…
People do take into account the motivations behind what someone says and to me the motivations here seem different enough to make some difference here. The AI CEO has an obvious motivation to lie, but the person calling BS doesn't have such a clear motive...
It's not the first article I've read recently that is an ad for AI after a short context pretending to criticize it, with nothing connecting them.
So yes, use AI. Don't nitpick the costs and benefits. The world is headed this way; if you want to develop software for a living and afford to eat, you need to be too.
Need more devs? Why? If a company was being profitable just fine prio AI era, they will still be profitable if they decide not to use AI. Shipping crap faster is not a formula for success. Shipping quality faster? I prefer shipping quality at a good pace
growth is much more important than profitability
I usually buy and use products that are simple and effective, and that get out of my way to do the thing that I want to do.
For email, I’m a happy customer of Fastmail and I’ve been paying them for years. I don’t care if they ever release a new feature and I’d never switch away from them to a competitor that’s less stable but does more. They release improvements slowly but they are very stable. But I would switch away from them if they start shoving AI into things or delivering subpar features that make my email worse.
For healthcare related websites, I can already see my test results, schedule appointments, and communicate with my doctor. What more could an AI-driven medical platform give me that makes my life better?
For maps — I unfortunately had to move away from Apple recently when they added Ads. So I’m mostly just using OpenStreetMaps. I could see AI improving the OSM functionality by updating the app (OrganicMaps) routing algorithms and such, so there is room for growth there, but it’s not that massive.
Can anyone offer features that Uber can’t now due to LLMs? There are a bunch of local Uber competitors but uber wins because it’s easy and there aren’t major features to differentiate there.
Do you have examples that prove that delivering a bunch of features really fast is going to steal customers from something?
ai is more than delivering features fast (thats probably one of the lowest priorities for companies)
right now its a race to automate work, especially back office. companies already are seeing 10M+ in savings and revenue growth and we're barely starting. workflows in sales, outbound, gtm, marketing, eng, operations, compliance, kyc etc
consumer is a different beast, consumers want convenience which has already been hyperoptimized and the big consumer cos run on network effs instead of features
They are implicitly saying that as a company, they don't want to be more productive. They want the same productivity by paying fewer more productive people.
Why is there an imbalance between what an employer gets paid for a unit of production and what an employee gets paid for a unit of production?
Because labor gets exploited to make the owners richer. That's the basic fact, even though the owners (as a class) have financed a lot of propaganda to justify and obscure it.
Only a person who never tried to organize labor into a company could ever have such a couch-sitter opinion
Granted, grandparent comment used _charged_ words. Let's rephrase: labor is used to ultimately provide owners more money than they put in.
Is that not a fair assesment of the real world? Who starts a company to lose money? Who starts a company solely for "creating jobs"?
What exactly is the beef with grandparent comment? Is it just the negatively charged words? It's the rephrased version beef-inducing as well?
I'd rephrase that: labor is used to provide the owners the maximum amount of money they can manage to extract from the people doing the labor.
A technology 10x's worker productivity? That means 9x more goes to the owners, and 0x (zero) more goes to the workers. Maybe the workers get even less, because now you can fire some.
> Who starts a company to lose money? Who starts a company solely for "creating jobs"?
A more equitable distribution of company profits does not imply the company loses money. It does not imply useless make-work jobs.
I fully agree, and remind you it's completely legal and simple for you to go and start a company that does equitable distribution of company profits. More people should do it instead of complaining that few people do.
I believe you mean same output but fewer people? But by definition that would be higher company productivity, as the definition of productivity at the company and/or national level is the ratio of outputs to inputs. If you have fewer people but are getting the same output, then the productivity of the company (or nation) has improved.
If you had fewer people but the same productivity then there would be no benefit to the company as the outputs would correspondingly be reduced (and it may actually be worse for the company if the company has any fixed costs).
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
Suggestion: we should all shift our terminology, and in particular make heavy use of phrase "...and it cost N lines of code". And say what we spent those LoC on.
"I implemented new feature X, and it only cost 200 lines!"
"That bug was brutal to figure out, but in the end it only cost 6 lines of code."
"It was doing something in case X that it didn't do in case Y, and it turns out that the distinction wasn't even needed. So I fixed the problem and saved 20 lines of code at the same time!"
Lines of code are a price you pay. We don't go around bragging about how we spent $200 without any mention of what we purchased with that money. Why do we do that with LoC? "I had to pay an extra $200 because I signed up late" and "I only paid $200 for my hand-painted artisanal pottery lamp hanger. Factory-made ones cost upward of $1200 on Amazon!" are two very different statements, and map to exactly the same distinction in code.
> If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster?
That shows that, in reality, it's short-sighted profit-taking. Boss just wants another lambo in the garage, and doesn't really plan to be around, when it's time to pay the piper.
Non-Functional requirements is a vestigial term from ‘function point analysis’ which is from the late 70s, and which also ended up being a proxy for LoC.
The entire industry is so focused on measuring now, and incentives are so skewed to short term that lagging indicators like maintainability are a non starter in many organizations that it will be challenging to fix this time.
Thats why it is so amazing for speed runs and prototypes. Here it is legitimately > 10X faster.
The more I read, the more I feel that 1 dev, 1 ai agent with the dev as a gatekeeper is probably the most appropriate workflow. Where you now treat the single dev + ai as a team in terms of planning and cost analysis and you get about 1.2-1.3x the throughput compared to a traditional team of 3-5 devs with partial PM and partial QA where the Dev now needs to take on those roles too.
The output should include more/better testing, examples, demos etc... since the bus factor is now 1, but AI is expected to be able to do the heavy lift.
Ugh. Just imagine the following on a normal curve:
Pre-AI: The goal is to make more money.
With-AI: The goal is to ship more code.
Post-AI: The goal is to make more money.
Can't wait to see how we get there...
But if you pair AI LoC in a range and also task completed in the same range and then compare that with historical data over a similar range without AI, then you have something tangible.
You also need to look at defect reports to understand the full picture of is AI being helpful.
So, we do need to measure AI LoC and AI PR counts, but we also need to make sure we are using other metrics to help paint the full picture.
https://www.goodreads.com/quotes/536587-measuring-programmin...
I wonder if we'll ever get back to that? If it's still relevant?
A) a newly-receptive audience - engineers who have discovered that they very much enjoy and appreciate the tradeoff of proximity to the code for amplified velocity and impact, now that it's possible to achieve without being a manager of messy human teams.
B) an ecosystem in which it's grown nearly impossible to connect a functional description of something to how much bespoke construction and effort was involved, partially because of marketing and partially because of how much software already exists to be built on top of. It's impossible to tell from a few paragraphs of functional description whether something was built in a weekend or took a team 4 years to ship, so volume of code is the natural fallback for describing complexity.
> why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue
Most roadmaps are full of garbage and would be better off being deleted. You get very few truly useful new features in a year.
To paraphrase ESR: the value to your customers is in them being able to know that can rely on your product still operating next year, not in those 20 new features.
Or to think about it another way, maybe block will be better off with fewer developers, but only if they produce sufficiently FEWER features so that they’re forced to prioritize.
I don't think so. Take a good company A (with a good product and a good pace of good features) of today. Take the extreme case they decide not to use AI at all. Well, they will still be shipping good features at their current pace.
No amount of AI will make a bad company ship a better product than A's. If any, bad/mediocre companies will be pushing crap faster than they did before, but that's it.
AI can make good companies better, but cannot make bad companies good. Why does company A need to worry about shitty companies using AI? Sure, other good competitors could be using AI, but all in all, shipping "faster" is not the "mark" of good quality
Skeptic and sceptic are pronounced identically, because they are just different spelling of the same word.
Maybe you've confused it with septic?
Since this is an area where failure can lead not to Instagram accounts getting hacked, but planes falling out of the sky and nuclear reactors spewing radioactive elements, it’s worth a close look. Some of the most visible companies in this sector include: QNX, Wind River, SYSGO, Lynx, Green Hills, Siemens Embedded, etc. None of them seem to have much if any adoption of LLMs for source code generation based on public statements.
Research in this area agrees with this view:
“In this paper, I have conducted a comparative analysis of the C++ code generated by popular LLMs including: OpenAI ChatGPT, Google Gemini, DeepSeek, Meta AI, and Microsoft Copilot for compliance with MISRA C++. The study revealed that none of the evaluated LLMs generated MISRA-compliant code despite clear prompts, with DeepSeek showing the fewest violations and Meta AI the most.”
> the perennially unprofitable venture-backed startup, for which faux productivity is connected to the generally immaterial nature of its high valuations, versus the game studio that lives and dies by the profitability of its products.
> In a sector of the economy where "it's not about how much you earn, but about how much you're worth," the labors of the companies whose workflows are built on the kinds of productivity apps that today comprise nearly 40 percent of Product Hunt's output are not actually directed at the creation of a thing, but at the appearance of the creation of a thing.
Maybe this is why Silicon Valley seems to have become obsessed with productivity and AI whereas the people in the industries you mention don't seem as excited. It's because they are actually making real things so they don't have to 'look busy' in order to justify themselves.
Yes yes, shout it from the rooftops! Over the next few years I think we're going to see that companies that get this point will keep doing meaningful things, and stand a chance of weathering this transition period.
I think we're going to see a bunch of companies that went all in on AI for AI's sake go under because they've lost their mission, lost their implementation, and won't have a way to get those back in a reasonable timeframe and at a reasonable cost.
I mean, if you give 219 people a free text box and ask them to explain anything, you're extremely unlikely to get the exact same answer twice...
Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.
So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited.
Teams have not re-organized to match the new code-input velocity.
Engineers don't want to do QA because it's "beneath them".. and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.
My day (excluding the huge amounts of communication overhead) used to progress as a serial operation of: 1. Write some code for one thing, 2. Self review of that thing, 3. Review other peoples' work, 4. Respond to review comments, 5. Get things merged, 6. Back to 1.
Now I have more of a tendency to queue up work on a few things at once, and then the serial steps are the self reviews and reviews of other peoples' work, and some of the review commentary back and forth (though I can automate some of this in parallel as well).
The upshot is that I'm more working in batches now than in serial, which I really do find to be more efficient.
It's not that it has removed all the bottlenecks at all, but no longer being required to focus all my attention for periods of time on physically typing code has removed one important bottleneck, and has changed, and I would say, improved, my workflow significantly.
But what's not as much the case is that if I did an A/B test on the same task that I'd be massively sped up because so much of my day to day work are the things you mentioned as being serialization points. The time I take to figure out what needs doing, what the best approach would be, making sure it was actually the right thing to have done in the first place once I'm done, all that stuff. I use AI assistance for those tasks too but it's not the same effect as when I just hand off the pure implementation phases. So it winds up being "faster" and you'll have to pry my AI assist tools out of my cold, dead fingers - but if I'm being honest with myself by *that* metric it's not a huge gain.
People. Already. Know. This.
It hasn't been the bottleneck for decades for the majority of products.
I’m fine with doing QA. But the fact is that it’s not how management measure my productivity. Spending hours doing QA looks like wasting time to them because it’s not an activity they track. They track my tickets so any hours not spent on them is literally harmful.
Also there’s the fact that you can’t QA your own output. It’s easy to overlook mistakes and defects.
> and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.
Just like QA, code review takes time. It’s easy to justify that time when the submitter has put in the effort to ensure that the contribution is worthwhile. Or can explain the design clearly. Not so much when it’s slop thrown over the wall.
> Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.
None of those are truly bottleneck. Deciding what to build is obvious: Something that solve a user problem. Reviewing code is easy when the intent of the code is clear (with additional prose if needs be). Testing code is equally easy and should already be automated.
The one slow activity has always been about designing the solution. And it has no relation to code. It’s mostly deep thinking and research. I do it on the sofa or in front of a whiteboard. If I’m typing, I already have a solution in mind.
I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)
This may be true, but they followed in May with this [0]:
> Importantly, survey results are not necessarily grounded in reality. There are reasons to be skeptical of people’s responses to counterfactual questions such as about AI’s effect on productivity — for instance, our study in early 2025 found that people overestimated AI’s effect on their time spent on tasks by 40 percentage points on average.
[0] https://metr.org/blog/2026-05-11-ai-usage-survey/#productivi...
> When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today. Show me that x% of your workforce is genuinely idle (or even just underutilised) because the work can now be done by fewer people. Even then: I’ve never seen a product/SaaS company that didn’t have an endless roadmap. If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue.
I see some people calling for calm instead of AI panic by invoking Jevons Paradox. But at least within these companies there's no good evidence of Jevons in action, is there? The roadmap is endless, but when employees are perceived to be idle they get fired instead of being assigned more (or more ambitious) tasks.
To be fair, one could claim Jevons applies to "the market" at large, but at least we can say the evidence from tech companies is not encouraging. So maybe it is, indeed, time to panic a bit?
> Choosing the layoff instead tells me the productivity claim is doing PR work for a decision that was already made for other reasons (over-hiring, investor pressure, take your pick).
Yup, I think we all suspect this. Though it's probably a mix of the two factors.
Anyone relying on a steady paycheck from an employer should panic a bit all the time, because nothing can save them from bad management. The reference to Jevons Paradox doesn't say anything about individual managers responding correctly. If 30% of managers screw up, that's a lot of collateral damage.
Now to respond to your actual point, I don't think software developers should panic. Even if pure software engineering gets hit hard, I'm having trouble imagining a scenario where years of software development skills plus knowledge in a specific domain isn't a good thing for current software developers. This is unlike what happened with international trade, where you had 60-year old textile workers losing their jobs, no alternative jobs, and no policy being offered to compensate them for the effects of trade.
Is it true that the evidence in tech so far is not encouraging? I was pretty worried about the job market a year or so ago, but it seems pretty good for experienced people at the moment, no? (I do have big concerns about the entry level pipeline though!)
This morning I reviewed a 1,200 LoC PR. Pretty large by pre-AI standards. But most of it was tests. Before AI, it would be a lot smaller, but only because the PR author wouldn't be nearly as diligent with test coverage as AI tends to be.
And to preempt some common rebuttals:
1. I always read the tests to make sure they are meaningful, and rules and subagent review routines in place to make sure stuff like "assert 1 == 1" or "Process.sleep(5000)" never make it in.
2. Tests do add a maintenance burden as well, but I find that it's pretty easy to refactor and condense tests.
Why?
> Be curious, try the new tools, test the latest models. To not do so is silly. > [...] > you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.
I really dislike these claims that act like they know the future of engineering, that they’ve been let in on some enlightenment that we haven’t been. What’s going to happen in a few months? Is Sam Altman going to nuke my house from orbit? Or is it because my CTO is going to fire me for not using AI? If it’s the latter, that’s not a curiosity problem, that’s a “there’s a gun to my head” problem.
If you want a more in depth explanation, go look for interviews with devs who were already super-productive before LLMs and now came around to using them everyday.
I still write code manually to keep my trad-coding skills from withering away, but using AI without a doubt has allowed me to better test my existing apps. Create playwright automations I would've never had the time for. Allowed me to search through docs many times faster. And it just making programming more fun when I do use it for more challenging problems, and I actually get something working at the end of the day.
That is why I have created one (Open Honest Slop Audit).
Basically the choices are:
1. Roll your own
2. Lockfile your deps for too long
3. Chase the bleeding edge for every dependency
The first is security-through-obscurity because DIY libs will have bugs and vulns but they won't be well-known. The second means missing known vulnerabilities. The third means supply-chain risk.
The rash of attacks and the ease of LLM-powered roll-your-own has shifted the risk-reward calculus towards 1.
But I hate it. This is the further Peter Pan never-gonna-grow-up of our industry that we cannot develop solid best-practice tools and must churn endlessly.
Funny how AI is continuing the same story of non/semi technical busy bodies with their dumb bullshit.
A few of my workflows now are: Use an LLM to generate code that generates code.
"Second Order AI Software Engineering(TM)"
As dang said in one of these threads recently, opinions are just spilt on this!
I spend a lot of my time taking over codebases other people left behind, and the AI-heavy ones have a recognizable shape: lots of plausible-looking code, thin tests, and nobody who can tell you why a given abstraction exists. Writing was never the hard part. Deciding what not to build, and being able to delete it confidently later, is the part that does not get faster with a model.
What did get faster for me is reading and reverse-engineering unfamiliar code - which is a little ironic, since the same tools are now producing more of the unfamiliar code that needs reverse-engineering in the first place.
Every line of code an LLM instantly spits out is a line a human engineer will eventually have to read, understand, debug, and migrate when the underlying business logic changes. The "better publicist" might be successfully selling these generation metrics to executives, but it's the actual engineering teams who are going to be paying the maintenance tax on all this auto-generated sprawl for the next decade.