This looks like measuring what is easy to do, rather than what really matters.
PR open counts, issues created , ceos/founders spending more time on linear don't automatically lead to better outcomes (in my experience they are often negatively correlated:-) )
This looks like measuring what is easy to do, rather than what really matters.
Even that's hard. There aren't enough signals to attribute changes directly to AI, so these apps seem to correlate the signal that the user was interacting with AI to the changes they made e.g "Bob used AI at that time, and they opened a PR at a similar time, so Bob probably used AI to make that PR."
Until the tooling for gathering data on AI usage improves the data will be fairly interesting because correlations often point to something related, but won't be a source of truth.
I'd be interested to overlay, I don't know, customer satisfaction or anything that can show the follow-on effect of all this output. Linear won't have that information.
My guess is some will jump up (where the team has managed to make themselves move effective and responsive) and many will plummet (doesn't need explaining).
I'd be interested to overlay, I don't know, customer satisfaction or anything that can show the follow-on effect of all this output. Linear won't have that information.
Very few businesses can accurately attribute customer value to the work they do, especially once they're passed start-up scale. A mature company makes lots of small changes and they're rarely measurable.
Yeah all of these along with raw token usage are metrics that were being used around December to February by people who just didn't have anything to go off yet.
Skill/Hook usage rates, budget spend, auto-approval rate, focus area heatmaps, MTTR, MTTD are all there now
Usage does not correlate with valued output or ROI. This article smells like a bad attempt to say hey guys our customers see ROI without any actual evidence that they do.
Also, somewhat amusingly, the “founder” consistently being at the top of the use curve might just have something to do with everyone else also using it, but that more implies people are using it because the chief at the top wants them to use it… not because it’s actually useful. A pattern that’s typical of bad AI deployments.
> Usage does not correlate with valued output or ROI
This sounds possible but how can we know? It could just as well correlate. Effort of all kinds correlates with success even when it's not obvious or not... linear.
If that was true then there wouldn’t be a giant ROI crisis fueling calls of an AI bubble burst imminent. If the answer was “the ROI is clear” then folks would just say that.
The debate about ROI isn't about whether everyone is going to throw their hands up and stop using AI tooling - the debate is about where that value is going to be captured. It's pretty clear that using some degree AI assistance for programming is on the whole faster and better than writing code by hand for the majority of applications, and it's clear that the degree to which it's better than writing code by hand is increasing quickly.
I'm sure someone is going to reply to and say "actually it's not clear and the tech debt is about to explode everything real soon now" or something to that effect, but it's hard for me to explain this theoretically when it is so obvious in practice in my day to day.
ROI doesn’t mean “does it help.” Few question if it helps.
ROI is about how much its costs vs the value of the “help.” That’s where the present crisis is. Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That’s a clear no at this point hence the growing panic.
> Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That looks like a clear no at this point.
That's only a potential crisis for those who have made concrete investments.
On the use side, the 'cost' of AI spans more than two orders of magnitude. Looking at recent models (<6mo) with reasonable performance (intelligence index >= 45) on OpenRouter, the output cost ranges from $50/MTok (Fable) to $0.153/MTok (DeepSeek Flash 0731).
From the perspective of a user of LLM/agent assistance, there's very likely a range where the benefits outweigh the costs.
If the ROI for the model developers isn't there, then that just impairs the future trajectory of the field. Current models are just bits that aren't going anywhere, and as long as they can be served (in inference) above their marginal cost they will continue to be so-delivered.
On the value capture question, it's really not clear that the ability to write code at superhuman speed actually translates to an increase in the speed with which we can create new, better technology products that customers will pay more money for, vs. just enabling layoffs.
You could say the same thing about compilers versus assemblers, high-level languages versus low-level ones, and services and libraries versus monolithic programs.
All other things being equal, increasing the speed of some part of the development process will increase the overall pace of development. However, By Amdahl's law that increase will be sublinear, and that is why we should take "pull requests" as an imperfect metric.
We also don't get to pick the form that 'better technology products' take. While we'd probably like to keep cost(/effort) and complexity constant and increase robustness and performance, the market equilibrium might be 'worse is better' and reward whiz-bang features and lower effort.
> You could say the same thing about compilers versus assemblers, high-level languages versus low-level ones, and services and libraries versus monolithic programs.
Right, but we didn't invest a trillion dollars of capital into any of those things in the span of a couple years, thus forcing them to capture value and show a return on such a massive investment.
Also, large companies are still experimenting on how to integrate LLMs into their workflows. Due to the fast cadence of releases, people forget that LLMs became robust (regardless of the capability level/parameter count/data size) enough to use semi-reliably in company-specific ways only 1 year ago. And bigger the org, the slower the process. I don't expect it to settle and get productive used across the majority of very large companies for another year atleast.
High prices are mostly a result of DC capacity. As more and more DCs get built out, prices will drop. At a unit level the inference business is extremely sound regardless.
If you make an effort to use the new tools effectively, the gains are wild. Don't fall into a grumpy luddite trap, the train is leaving the station and you'll struggle to catch up if you don't learn and grow.
Not using AI for software development in 2027 will be like only knowing how to program via punchcard in 2010.
It's new. It's different. It's hard. It's your job. Learn how to use it effectively, embrace the new abundance mindset.
Children will jump on any train, that's why I'm in computers, and why there's an AI cheating crisis right now so severe that nobody is learning anything in schools.
> If you make an effort to use the new tools effectively, the gains are wild. Don't fall into a grumpy luddite trap, the train is leaving the station and you'll struggle to catch up if you don't learn and grow.
Correct, in fact you can tell most AI detractors aren't thinking about this from a _computer science_ point of view. You'll have many people claiming "why prompt an LLM when you can write it and commit it yourself in 45 minutes?" True, you could. But that's a purely _serial_ workload. LLMs are effectively data-independent and they can.. work in _parallel_. Meaning instead of working on a single task, you can juggle multiple simultaneously. So even if you're as fast or faster on a one-on-one basis, you _cannot physically_ be faster than 10 separate sessions running in parallel, working on wholly separate tasks. And that's actually where most 10x gains come from. See Amdahl's/Gustafson's laws.
His comment sucks but it is indeed a skill issue. Not the skill of "agentic coding" or whatever but the skill of having and communicating good ideas. A lot of engineers/people are bad at that, and are struggling to produce anything of value with AI coding.
I program as a hobby, personal projects because I can.
I recently set up a local llm to see what the fuss is about and other than the few ringer solutions my experience is as you described. 2min promping, 5min waiting, 3hrs debugging or just doing it myself.
I am very likely doing it wrong, and it does speed up some aspects, but I wouldn't say I trust llm code any more than my own. Until it runs and throws an error, the llm is 100% confident that it has written perfect code.
Models that run on (average) consumer hardware are not even close to comparable to models like Fable or Sol. Its like comparing an ant to the largest dinosaur.
A normal agentic loop will have the agent using a type system and basic tests to do some basic validation of changes. A good agentic loop would give the agent a very easy way to verify if it’s on the right track. I think agents are better than many humans at writing error free code (runtime errors, not bugs. The code could still be buggy or incorrect.)
That has been my experience as well. Having the agent have full access to what it is building feels like a cheat code. A recent example: Godot (the game engine) has a feature where GPUParticles can spawn another particle system when they collide with something. Today (as in, download the engine right now and see it for yourself) this is broken, particles spawn beneath the collision box and the faster the particle is the worse it is.
So I asked Claude to first figure out a way to instrument GPU particle code so it could itself check his solutions. After that I left the agent running for 3 hours and it came back with a solution (continuous collision detection) and a bug fix (particles get their velocity applied an extra frame after colliding). I'm sure someone would find something to complain about the code (which is why I haven't upstreamed it) but it looks visually perfect and I had plan to fork the engine for my project anyway
Fundamentally though, an agent cannot produce great code, because great code requires intent, which is the opposite of the statistical mean.
You will get a solution that works with a proper workflow, but you won't get one that scales or would be truly maintainable.
Which is also what you get with random midwit drive-by contributors, but faster. I'll give it that.
I'm not sure I agree that LLMs solve for the statistical mean
But more importantly: isn't what you call "intent" just a series of optimization goals? You want your code to satisfy the constraint of being correct™, while also maximizing various other goals like being maintainable, easy to understand, having few lines of code, as little tight coupling as possible, etc. Goals that often conflict, but when given two implementations you could likely tell which hits the better tradeoff (in your engineering experience)
Those are all things that theoretically - with a tight enough specification and enough compute - a constraint solver could solve. No human intent necessary.
The issue is more that we can't fully specify all those side goals, and even if we could the LLM would struggle following them. A classic paperclip maximizer problem (where nobody told the paperclip maximizer to keep the planet inhabitable and all the other side conditions we implicitly assume)
> I'm not sure I agree that LLMs solve for the statistical mean
The good thing is that you don't have to agree with that, as the fundamental technical reality does it for you. LLMs do work like that. They are just statistics and probabilities.
Doesn't the universal approximation theorem apply to typical LLM architectures? LLMs solve for the shape of the input data, as well as they can approximate it in the constraints of their architecture, the optimizer and the amount of compute spent in the training process
And where those constraints prevent us from matching the shape there is no guarantee that we match anything like the mean. Though maybe we can agree that that's where the optimizer would tend to steer towards when it can't do any better
If you built a task management system, you'd have very different code bases depending on whether it's for internal use at a mid-size development org or as a SaaS.
So I wonder whether, in your experience, the results you've seen, could have improved by providing sufficient context? - or what context was given.
I.e. if you have the agent that same context, as one of your colleagues would have/require to solve a problem.
You've missed my point. I didn't dismiss agents. I did dismiss the industry.
I don't need to add more context to a statement that operates on a layer above where context injection would influence it. It is a conceptual impossibility. Not a technical roadblock.
This is a weird framing, but the user is the "intent". If you can produce "great code" by yourself (whatever that is), then you can get your agent to produce it for you. If you are talking about vibe-coding then yeah, it is going to be trash
If can put properly engineered intent in the prompt that is verifiable, it works wonders. Anything that can defaults to the llm doing its way, you're right, it just can't converge to good, not with proper constraints.
Once agents run autonomously for longer periods preventing vision drift becomes as important as correctness.
Epiq solves this with an architecture that supports workflow auditing, allowing you to time-travel state in a filtered view to reconstruct what happened, when, by who, and where intent started drifting, while also allowing you to correlate the evolution of the board with the corresponding commits.
What I've observed is that by prompting for longer I get to keep my brain focused on the architectural ideas (networking, protocols, data structures, etc) rather than worrying about the most performant/elegant implementations.
I always enjoyed writing code and I am very good at writing very performant and elegant code, but it would sometimes come at the detriment of focusing on the code and not the design.
Absolutely, have warned my juniors of this. Doesn't stop malicious compliance though, I can just prompt and burn tokens with source material from my assigned tickets for no reason perfectly fine.
I look at my colleagues' screens and they're prompting shit like 'restart this program' and 'is [service] running correctly'. I have below average prompt frequency because I know crazy shit like #!/bin/bash and ps aux. It's so goddamn insane.
And to top it all off, my token count is above the average, it's just the prompt count that is low. Got questioned about it earlier this week.
I tried hard to tokenmaxx one month and couldn’t do it as for most tasks, I’ve already figured out the solution while reading the ticket and vim/emacs-fu is more enjoyable than prompting and waiting. And for other tasks, I just knew the technology to do something with the least amount of effort.
To be fair, I've been wanting to move to vim or emacs for a while now, but I've customized and gotten used to my current editor so much that it doesn't feel like a week's task.
It used to be that one person had one to three codebases they knew intensely at my company. If you needed a bug in codebase X fixed, person Y was the one to do it and if they aren't available, person Z can do it, just not as quickly.
Now every person on my team has to handle tickets for every single codebase. There are about two dozen different large codebases involved here.
It's a ludicrous antipattern because person Y still needs to review the PR that person A generated for codebase X, and it will take them about as much time to wrangle the 2000 line PR (oh boy do LLMs love their mocks for unit tests) as it would have been for them to do the 50 line code change.
On top of that, it has "allowed" us to add feature after feature onto codebases not designed for them without refactoring. Is it good that this Flask API went from a purpose built service that interacted with the data analytics for product A stored in database X, and now our sales guys can sell product B, C, and D stored in database X? Uh, I'm sure it's great for them. Oh, and now it all can be stored in database X, Y, or Z depending on what the customer wants or what sales promised them. Great. Now I'm looking at a Flask app.py that's 12,000 lines of repeated code.
It has allowed poor designs to still produce working code. For a while. We seem to be getting a lot of bugs lately that look really bad to customers because it's for really simple shit. And I can't help but notice that happening to all the various products and sites I use too...
Companies are tracking token usage across the board. You are in trouble for too less or too many. Unfortunately the token usage is the only measurable thing for most folks so everyone is playing the game, otherwise how else would Anthropic and OpenAI make the money
Writing code directly takes longer to warm up. Usually, I'd keep tens of thousands of lines in my head. In the past, I spent a lot of time designing error propagation and execution contexts. (Talented people might figure it out right away, but unfortunately I don't have that kind of talent.) So I'd have to think about things like Result<T> and how far to propagate errors—and worry about whether my approach would conflict with the existing codebase.
But these days, AI just generates code following the existing patterns of the codebase. In the past, staring at a blank screen meant going through a checklist of things to design—starting from policies and writing everything down step by step. Now, I just ask AI and it gives me a template—which is great. Then if the AI makes a mistake, I fix it manually.
Of course, I still hand-code sometimes—but only in the areas I enjoy. Most of the time, I use AI coding. Both are fun, and they complement each other in interesting ways. Doing both together is actually enjoyable.
For me, coding is either a flow state (when I have huge swaths of code to write) or deeply thinking about just a few lines (mostly to figure if I caught everything). The latter case is when I procrastinate the most, because I usually have an idea of a solution, but don’t want to do the work of actually verifying if it’s correct. Using AI then is skipping the enjoyable part (writing the code) to the unpleasant part (formulating hypothesis and verifying them).
I feel similarly, but at the same time, I think I am the exact opposite. I actually find formulating hypotheses more fun.
For hobby projects or things I start casually, I usually do not think about errors and such at all. When it is a tool I want to build or need for myself, I really do not care about that part.
In my case, I do not contribute to open source at all. Mostly, I deliver code for factory systems or specific companies, and usually, there are strict enterprise requirements. (To be precise, there is always that mandatory code the lead developer on their end dictates, right?) That kind of code is mostly no fun, but it has to meet their requirements and often clashes with my own style. Having AI write that code for me is a huge relief.
In that sense, I think it is just a difference in personality and preferences. I originally became a programmer because I wanted to make games. I started programming because I found it fascinating to see things drawn and displayed on the screen. Becoming a programmer was all because making Flash games was so much fun... So in that regard, for me, writing code is just 'drawing what I want on the screen', which is why I guess I do not mind if the code is written by AI.
When I contribute to other people's projects, I do not use AI for anything other than English translation, but for my own projects, I have no hesitation.
Is this really just a difference in inclination? It is not that I did not enjoy writing code, but rather that seeing what I want rendered on the screen brings me more joy.
When the concept of 'vibe coding' first came out, I really hated it (since my knowledge was earned over 4 to 5 years of getting scolded by lead developers as a subcontractor and factory software provider). But thinking about it, what I really wanted to do as a developer was just to build the worlds I envisioned, so I decided not to let it bother me too much.
We talk often here on HN, and I really enjoy debating with you. I learn a lot from you.Mr."skydhash", I actually remember you quite often, and I even steal a few keywords from your posts sometimes. Because we have different tendencies, we occasionally clash, but having these conversations is exactly what makes it enjoyable.
Thank you for always replying. Have a great day, and I hope this does not offend you in any way.
> Is this really just a difference in inclination? It is not that I did not enjoy writing code, but rather that seeing what I want rendered on the screen brings me more joy.
I've been tinkering with things since a very young age, started learning about computers in middle school and really started with programming in college (I had the basics since high school, but I was interested more in 3D modeling). So writing code is more like tinkering for me and I don't really particularly care about the result other than making it happen (correctly). Once it's done, it's no longer a subject of intellectual interest.
So the joy of creating a program is in the creation itself. Once it's done I merely use it (or maintain it if it's part of the work).
I don't condemn AI use, even when doing vibe coding. My main issue is with the hypers stating that it's ok to lower a codebase quality or encouraging recklessness (and the dubious anecdotes) in a collaborative settings. If you can ensure quality and collaborate easily with your colleagues, go ahead. If you can't, then you shouldn't send PRs around.
> Thank you for always replying. Have a great day, and I hope this does not offend you in any way.
Have a great day too. I always appreciate the different point of views on a subject. It's a big world and everyone has their own perspectives.
>If you can't, then you shouldn't send PRs around.
I think this is exactly why our differences emerge.
I rarely collaborate with colleagues. In contract delivery work, that is simply how things operate. Usually, after the architecture is divided into modules, I take on the role of implementing one entire area from start to finish. Because of this, I actually have almost no experience with direct code level collaboration.
While multiple developers typically share a single code base and constantly exchange PRs, I take full responsibility for the internal implementation within the designed I/O interfaces, which seems to be where our divergence stems from.
When the modules are finally integrated, it only becomes a matter of accountability. In that sense, aside from my own website, I might not actually be doing any sustainable development. To be honest, as you know if you try AI vibe coding, the AI's abstraction and my abstraction are different. Because I am not used to its structure, it is not easy for me to manually fix the code generated by AI. Even if I do fix it, I mostly just tweak the surface level. In that regard, I completely agree that there are valid concerns regarding long term maintenance. However, since meeting strict deadlines and ensuring the required behavior are more important to me than long term maintainability, I tend to be more lenient toward AI generation.
It seems we reached different conclusions because we operate in completely different domains. It is always fascinating to see how perspectives differ depending on the field when having these conversations. Have a nice day.
I read these kinds of comments and wonder what makes reality so different for us. I personally have found AI has the easiest time in the world following existing patterns. At my workplace, our frontend code is so well organized most of the time all the AI has to do is copy and paste an implementation from somewhere else and change the names, and it gets right pretty much 100% of the time
Every workflow is highly personal, so there's no real reason to argue about it. Depending on the work, some tasks become patternized and others don't. Most people overestimate themselves as being near average, and some of them are actually unskilled. There's no point in fighting with them.
Even on HN, people don't comment purely out of 'rationality.'
I think AI generates well patterned code. Essentially, it handles a lot of situations with standardized code. But recognizing those patterns and knowing how to implement them are different things.
In programming, there are people who know how to implement something but can't explain the contract or the model behind it. For those people, AI might not be very useful, or they might be one of the rare few who write code far better than AI. Either way, the fact that an AI beat a top competitive programmer is enough to say it performs better than most people on HN. There's no point in arguing with them.
It's not that they're necessarily wrong. It's that they tend to generalize their own personal workflows.
AI can't do software engineering, but it can code well. Software engineering is the problem of transforming a complex open system into a closed one, taking a PM's requirements and building a single system out of them. AI can't do that. Why? Because AI can't adjust emphasis the way humans do. The design for frequently accessed parts and rarely accessed parts should be different, but AI treats everything uniformly, which makes it harder to modify later.
On the other hand, once a problem is closed and well defined, AI does much better than most people. It's logical and doesn't make the kind of leaps humans do, at least with frontier models. So there's no point in arguing with them at all.
Their experiences are based on their own workflows, so their perceptions naturally differ. And it's hard to tell whether they're saying it's bad because they truly understand it well, or because they don't understand it at all.
I'm not saying they should live in an echo chamber, but there's no reason to argue with them. It's better to trust statistical facts.
Could be a symptom of which languages we use and which languages are in their training sets. I primarily write F#, which is a functional language that's compatible with the object-oriented C#. When AI tries to write code in my F# codebases, it almost always ignores the existing patterns/styles and tries to write it like an OO language. It has a weird desire to use mutability instead of the default immutability, for loops instead of pipes/monads, huge if/else blocks instead of pattern matching, etc. This is all very un-idiomatic for F#, not what a human programmer would write unless they were deliberately trying to write it like C#.
Maybe it's better in Fable/Sol, but it was a problem in Opus when I still used Claude, and it's still a problem with the Qwen and Deepseek models I use now. Either way, it seems to me that your code has to already conform to the patterns they want to write, or you're going to end up with new patterns.
To be fair, I do have to remind the AI to follow the codebase's conventions regularly and it is the #1 rule in our team's claude.md. And when I generate plans I ask that every new implementation follow a reference implementation. In your F# projects would something like that help or would it make no difference?
Yeah that's what I've ended up doing and it does help. I do have guidelines set up in my agents.md files, but they're hit or miss. It's best to just tell them directly to "write idiomatic F#," which they seem to understand.
Well you got me. I’d agree about that workflow, but something more rapid like a few seconds generating code and then a couple minutes reading it can be more engaging to me than writing it out yourself. I think it’s near time we all stop having such strong opinions about the matter either way personally.
Yeah I kinda agree. The AI boosters have been super annoying for a while.
I’m not anywhere close to an AI booster but I find value in it. I think we should think of it less like some intelligent being or “agent” and more as a code generation tool. It would both be more productive and healthier.
It’s worthwhile to me under specific conditions, mainly that the codebase has existing patterns and abstractions that the LLM utilizes, and they’re actually good. It’s not a common case but I’m lucky that one of the codebases I’m in is one I built myself mostly by hand, and LLMs are really effective in it at the moment. My main concern is making sure the generated code maintains the high standard, but it’s definitely saving me time.
I’ve kind of changed my mind on prompting, it’s definitely a skill. It’s a skill based on your own skills in the domain. I’m at the point where I can get the LLM to generate the same code (roughly speaking) that I would have written. So it’s basically generating the same thing I would write, just faster. So it’s like reading your own code. Using it as a crutch to do things you aren’t capable of is where people run into trouble. That’s where the massive amounts of code review come into play. For me, I’m only ever reviewing 100-300 loc changes at a time. Often less. Because I know what I’m doing and can break things down into manageable diffs.
Can’t see myself going back, but also can’t see myself doing it without the experience I have without LLMs. Which is a bit of an issue for new developers. Not sure what the solution is for that.
I’ve reached a similar conclusion, but there’s a part that worries me: the expertise that allows us to judge AI’s output was itself built by doing the work we’re now delegating. So there’s a risk that our judgement will decay over time. I’ve been thinking about the problem as choosing where we can afford to “borrow” comprehension, versus where we need to keep exercising it, and how to “claim back” the critical comprehension we lost.
A possible heuristic: Everywhere the LLM made a design decision is probably a place to revisit later. You can ship it now, but to stay in the game you need to stay in the loop.
If you need the LLM to explain to you the concept behind something - or even if you figure out yourself what it did - that's likely wrong and will lead to the undesirable outcomes you've mentioned.
As long as it just types and doesn't think otoh, you should be good. There is - I'd argue - little to no value in manually typing if (foo) {}. And it's also great for bouncing ideas around.
That plus if you’ve ever stared at your code and then searched StackOverflow to see if you could find a better way of doing it, it’s like having that running continuously.
this seems inappropriate. I think its a bad paradigm that just because you use a platform's service, they get intimate details about your usage. And for them to be so bold about publishing the statistics they've stolen from their customers data? Gives me a reason to never recommend my org use this platform.
I think their point is that there's business value in the usage data and linear is using that value in a way that benefits them but not the customers they got it from.
It reminds me of matt levine's reframing of insider trading where it's not about fairness it's about theft. You're supposed to get secret insights and use them to get an edge. What you can't do is get an edge for yourself with secret insights that your employer got.
So it roughly comes down to "that data is valuable and rightfully belongs to the originating company." Which then makes this a contract diligence type situation.
My company uses Linear. The data presented in this blog post is worthless to me and the company. It can be crudely summarized as “agents and agentic development processes are conducting more Linear operations.” Duh!
I’d rather it was published for free in a blog post than sold without my knowledge. As a linear user. This shit doesn’t matter, everyone in the industry know these kinds of stats are being tracked, I’m happy for a company to be transparent about it.
Why would a company want to leak its processes and workflows to another company in a capitalist system. Seems sloppy and a short sighted transfer of wealth to external stockowners.
Oh hey! My industry. Guess what? ADP doesnt just yoink your data. ADP conducts voluntary surveys on the scale of hundreds of thousands. Voluntary. ADP also pays for it for the most part. Do you think Linear conducted..voluntary surveys here?
"Pull requests are up 111% in two years".
Would be more honest to say that the number of pull requests "detected" by linear are up XXX%.
Because it only works if you setup git repo tracking and use it properly. And at that point it is not obvious if more teams are using linear and using it correctly, or if the number of PR really increased that much!
Doubling PRs isn't necessarily unbelievable. AI reduces ceremony around PRs, makes the small shitty changes that you never had time to do possible and the larger cleanups at least doable.
This looks like a "We are so AI native and efficient!!" article. At least, they could delve deeper into how they define the metrics and how they collected the data.
This is pretty interesting but I wish it would have been refined in two ways:
- The prose before the data appears to be AI generated. Not a big deal but it makes the reader work harder to figure out what's actually being said.
- Linear didn't control for their platforms AI changes over the past year. The platform has become much more AI integrated, so a lot of numbers will move. I'm not sure how you do it but this is only useful signal with a control.
> Time spent on customer requests, docs, and projects held steady [..] AI has so far changed how teams execute far more than how they decide what to build
I think the measurement for this may be flawed. We do mostly use AI to decide how to build. But what we build is influenced by AI-driven research into a problem or task. That's largely done in coding and desktop AI tools, not Linear Asks/AI.
I'm working on accelerating my team's work by implementing AI-driven code pipelines with guardrails to eliminate as much unnecessary review time as possible. Also making a chatbot for turning repetitive tasks & PRs into buttons, and an "architectural guidance" chatbot that gives advice tailored to our business, software/system architecture, cloud, standards, etc. This puts AI and automated jobs in the center of both how (automated task) and what (architecture guidance).
But this has a not-so-great implication for Linear. With my tools, a human never has to touch a ticket, so we could use any ticketing system with an API or CLI. Linear is a great product because they made a great interface. What happens when I replace their interface with a chat bot?
Founders topping the usage chart says more about org pressure than product value. Adoption driven from the top looks different from adoption driven by results.
The bullshit asymmetry principle suggests that once something is identified as bullshit, we shouldn't spend much time to write an excruciatingly detailed refutation.
Invoking the bullshit card on opposing views, in order not to have to elaborate your own pov, seems counterproductive, if the aim of your participation in a discussion is to test your own hypotheses about the world - or in any way gain or deliver insights.
I might build a Chrome extension that looks for “AI” in HN submission titles and shows a fake comment at the start saying “AI is all slop garbage that’s total slop and I hate it. AI sucks and it’s slop!”
It will save people time reading the 5-10 other identical vacuous comments
Rebuttal to what? I’m complaining that it’s a totally pointless comment that could be used on any AI related post. The comment just says “AI is slop garbage that sucks”.
What am I going to say to that? Obviously it can’t suck that badly or there wouldn’t be a large majority of programmers using it, plenty of famous programmers and developers of languages praising it, millions of people paying for $200 plans. It doesn’t need to be Carmack-level to get a massive amount of use out of it when you can just say “implement this chart here, give me some ideas on speeding up this algorithm, write a function that converts this heightmap to a .fbx” and it writes it.
This looks like measuring what is easy to do, rather than what really matters.
PR open counts, issues created , ceos/founders spending more time on linear don't automatically lead to better outcomes (in my experience they are often negatively correlated:-) )
This looks like measuring what is easy to do, rather than what really matters.
Even that's hard. There aren't enough signals to attribute changes directly to AI, so these apps seem to correlate the signal that the user was interacting with AI to the changes they made e.g "Bob used AI at that time, and they opened a PR at a similar time, so Bob probably used AI to make that PR."
Until the tooling for gathering data on AI usage improves the data will be fairly interesting because correlations often point to something related, but won't be a source of truth.
I'd be interested to overlay, I don't know, customer satisfaction or anything that can show the follow-on effect of all this output. Linear won't have that information.
My guess is some will jump up (where the team has managed to make themselves move effective and responsive) and many will plummet (doesn't need explaining).
Then there might be something to look at.
I'd be interested to overlay, I don't know, customer satisfaction or anything that can show the follow-on effect of all this output. Linear won't have that information.
Very few businesses can accurately attribute customer value to the work they do, especially once they're passed start-up scale. A mature company makes lots of small changes and they're rarely measurable.
Yeah all of these along with raw token usage are metrics that were being used around December to February by people who just didn't have anything to go off yet.
Skill/Hook usage rates, budget spend, auto-approval rate, focus area heatmaps, MTTR, MTTD are all there now
[dead]
Usage does not correlate with valued output or ROI. This article smells like a bad attempt to say hey guys our customers see ROI without any actual evidence that they do.
Also, somewhat amusingly, the “founder” consistently being at the top of the use curve might just have something to do with everyone else also using it, but that more implies people are using it because the chief at the top wants them to use it… not because it’s actually useful. A pattern that’s typical of bad AI deployments.
> Usage does not correlate with valued output or ROI
This sounds possible but how can we know? It could just as well correlate. Effort of all kinds correlates with success even when it's not obvious or not... linear.
If that was true then there wouldn’t be a giant ROI crisis fueling calls of an AI bubble burst imminent. If the answer was “the ROI is clear” then folks would just say that.
The debate about ROI isn't about whether everyone is going to throw their hands up and stop using AI tooling - the debate is about where that value is going to be captured. It's pretty clear that using some degree AI assistance for programming is on the whole faster and better than writing code by hand for the majority of applications, and it's clear that the degree to which it's better than writing code by hand is increasing quickly.
I'm sure someone is going to reply to and say "actually it's not clear and the tech debt is about to explode everything real soon now" or something to that effect, but it's hard for me to explain this theoretically when it is so obvious in practice in my day to day.
ROI doesn’t mean “does it help.” Few question if it helps.
ROI is about how much its costs vs the value of the “help.” That’s where the present crisis is. Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That’s a clear no at this point hence the growing panic.
> Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That looks like a clear no at this point.
That's only a potential crisis for those who have made concrete investments.
On the use side, the 'cost' of AI spans more than two orders of magnitude. Looking at recent models (<6mo) with reasonable performance (intelligence index >= 45) on OpenRouter, the output cost ranges from $50/MTok (Fable) to $0.153/MTok (DeepSeek Flash 0731).
From the perspective of a user of LLM/agent assistance, there's very likely a range where the benefits outweigh the costs.
If the ROI for the model developers isn't there, then that just impairs the future trajectory of the field. Current models are just bits that aren't going anywhere, and as long as they can be served (in inference) above their marginal cost they will continue to be so-delivered.
On the value capture question, it's really not clear that the ability to write code at superhuman speed actually translates to an increase in the speed with which we can create new, better technology products that customers will pay more money for, vs. just enabling layoffs.
You could say the same thing about compilers versus assemblers, high-level languages versus low-level ones, and services and libraries versus monolithic programs.
All other things being equal, increasing the speed of some part of the development process will increase the overall pace of development. However, By Amdahl's law that increase will be sublinear, and that is why we should take "pull requests" as an imperfect metric.
We also don't get to pick the form that 'better technology products' take. While we'd probably like to keep cost(/effort) and complexity constant and increase robustness and performance, the market equilibrium might be 'worse is better' and reward whiz-bang features and lower effort.
> You could say the same thing about compilers versus assemblers, high-level languages versus low-level ones, and services and libraries versus monolithic programs.
Right, but we didn't invest a trillion dollars of capital into any of those things in the span of a couple years, thus forcing them to capture value and show a return on such a massive investment.
Yep.
Also, large companies are still experimenting on how to integrate LLMs into their workflows. Due to the fast cadence of releases, people forget that LLMs became robust (regardless of the capability level/parameter count/data size) enough to use semi-reliably in company-specific ways only 1 year ago. And bigger the org, the slower the process. I don't expect it to settle and get productive used across the majority of very large companies for another year atleast.
High prices are mostly a result of DC capacity. As more and more DCs get built out, prices will drop. At a unit level the inference business is extremely sound regardless.
[dead]
It's hard to measure ROI so we generally wouldn't. Even McKinseys and BCGs have a hard time showing ROIs.
Sure, you could say all digital transformations are nebulous snake oil and don't deliver but I just don't think this is the case.
[dead]
Considering many of them are starting from an existing product and making it worse, they're -10x
[dead]
Skill issue.
If you make an effort to use the new tools effectively, the gains are wild. Don't fall into a grumpy luddite trap, the train is leaving the station and you'll struggle to catch up if you don't learn and grow.
Not using AI for software development in 2027 will be like only knowing how to program via punchcard in 2010.
It's new. It's different. It's hard. It's your job. Learn how to use it effectively, embrace the new abundance mindset.
>> Don't fall into a grumpy luddite trap, the train is leaving the station and you'll struggle to catch up if you don't learn and grow.
If that's true things are truly hopeless for pre-school/school children who are not in position to jump on the train just yet.
Children will jump on any train, that's why I'm in computers, and why there's an AI cheating crisis right now so severe that nobody is learning anything in schools.
> If you make an effort to use the new tools effectively, the gains are wild. Don't fall into a grumpy luddite trap, the train is leaving the station and you'll struggle to catch up if you don't learn and grow.
Correct, in fact you can tell most AI detractors aren't thinking about this from a _computer science_ point of view. You'll have many people claiming "why prompt an LLM when you can write it and commit it yourself in 45 minutes?" True, you could. But that's a purely _serial_ workload. LLMs are effectively data-independent and they can.. work in _parallel_. Meaning instead of working on a single task, you can juggle multiple simultaneously. So even if you're as fast or faster on a one-on-one basis, you _cannot physically_ be faster than 10 separate sessions running in parallel, working on wholly separate tasks. And that's actually where most 10x gains come from. See Amdahl's/Gustafson's laws.
Is this mean-spirited comment really what you want to share as the face of your company?
I don’t know this person but no one else is holding back on mean spirited replies, I see no reason they shouldn’t reply in same.
[dead]
His comment sucks but it is indeed a skill issue. Not the skill of "agentic coding" or whatever but the skill of having and communicating good ideas. A lot of engineers/people are bad at that, and are struggling to produce anything of value with AI coding.
This but the train is competence (the opposite of AI) and it has already left.
The AI whisperer! The hottest job title of 2026!
> It's new. It's different. It's hard. It's your job. Learn how to use it effectively, embrace the new abundance mindset.
This. Except it’s not that hard to get proficient. Either learn it or get left behind same as it ever was in software tech.
[dead]
> spent millions on AI contracts
The key question is how much value has been delivered on the other end for a given cost. Well used, tokens would be cheap at 10x the price right now.
Care to share your costs and revenues then?
[dead]
[dead]
These days, my work has become: generate code for 20 minutes, then spend an hour reading it.
And then more hours cleaning it up and re-prompting.
I program as a hobby, personal projects because I can.
I recently set up a local llm to see what the fuss is about and other than the few ringer solutions my experience is as you described. 2min promping, 5min waiting, 3hrs debugging or just doing it myself.
I am very likely doing it wrong, and it does speed up some aspects, but I wouldn't say I trust llm code any more than my own. Until it runs and throws an error, the llm is 100% confident that it has written perfect code.
Models that run on (average) consumer hardware are not even close to comparable to models like Fable or Sol. Its like comparing an ant to the largest dinosaur.
You don’t even have to go that far, recent Opus models are quite impressive.
A normal agentic loop will have the agent using a type system and basic tests to do some basic validation of changes. A good agentic loop would give the agent a very easy way to verify if it’s on the right track. I think agents are better than many humans at writing error free code (runtime errors, not bugs. The code could still be buggy or incorrect.)
That has been my experience as well. Having the agent have full access to what it is building feels like a cheat code. A recent example: Godot (the game engine) has a feature where GPUParticles can spawn another particle system when they collide with something. Today (as in, download the engine right now and see it for yourself) this is broken, particles spawn beneath the collision box and the faster the particle is the worse it is.
So I asked Claude to first figure out a way to instrument GPU particle code so it could itself check his solutions. After that I left the agent running for 3 hours and it came back with a solution (continuous collision detection) and a bug fix (particles get their velocity applied an extra frame after colliding). I'm sure someone would find something to complain about the code (which is why I haven't upstreamed it) but it looks visually perfect and I had plan to fork the engine for my project anyway
Fundamentally though, an agent cannot produce great code, because great code requires intent, which is the opposite of the statistical mean.
You will get a solution that works with a proper workflow, but you won't get one that scales or would be truly maintainable. Which is also what you get with random midwit drive-by contributors, but faster. I'll give it that.
I'm not sure I agree that LLMs solve for the statistical mean
But more importantly: isn't what you call "intent" just a series of optimization goals? You want your code to satisfy the constraint of being correct™, while also maximizing various other goals like being maintainable, easy to understand, having few lines of code, as little tight coupling as possible, etc. Goals that often conflict, but when given two implementations you could likely tell which hits the better tradeoff (in your engineering experience)
Those are all things that theoretically - with a tight enough specification and enough compute - a constraint solver could solve. No human intent necessary.
The issue is more that we can't fully specify all those side goals, and even if we could the LLM would struggle following them. A classic paperclip maximizer problem (where nobody told the paperclip maximizer to keep the planet inhabitable and all the other side conditions we implicitly assume)
> I'm not sure I agree that LLMs solve for the statistical mean
The good thing is that you don't have to agree with that, as the fundamental technical reality does it for you. LLMs do work like that. They are just statistics and probabilities.
Doesn't the universal approximation theorem apply to typical LLM architectures? LLMs solve for the shape of the input data, as well as they can approximate it in the constraints of their architecture, the optimizer and the amount of compute spent in the training process
And where those constraints prevent us from matching the shape there is no guarantee that we match anything like the mean. Though maybe we can agree that that's where the optimizer would tend to steer towards when it can't do any better
If you built a task management system, you'd have very different code bases depending on whether it's for internal use at a mid-size development org or as a SaaS.
So I wonder whether, in your experience, the results you've seen, could have improved by providing sufficient context? - or what context was given.
I.e. if you have the agent that same context, as one of your colleagues would have/require to solve a problem.
"You're holding it wrong"
You've missed my point. I didn't dismiss agents. I did dismiss the industry.
I don't need to add more context to a statement that operates on a layer above where context injection would influence it. It is a conceptual impossibility. Not a technical roadblock.
This is a weird framing, but the user is the "intent". If you can produce "great code" by yourself (whatever that is), then you can get your agent to produce it for you. If you are talking about vibe-coding then yeah, it is going to be trash
> because great code requires intent
If can put properly engineered intent in the prompt that is verifiable, it works wonders. Anything that can defaults to the llm doing its way, you're right, it just can't converge to good, not with proper constraints.
[flagged]
Do you people ever think of anything else other than pitching your next SaaS startup thing?
Holy crap. Does your home have mirrors?
Once agents run autonomously for longer periods preventing vision drift becomes as important as correctness.
Epiq solves this with an architecture that supports workflow auditing, allowing you to time-travel state in a filtered view to reconstruct what happened, when, by who, and where intent started drifting, while also allowing you to correlate the evolution of the board with the corresponding commits.
https://ljtn.github.io/epiq
[dead]
I don't think setting up a local LLM is a reasonable way to get a good idea of how enterprises are using this stuff.
Try using Fable and report back. Local LLM is to Fable as Little Tike car is to a Porsche.
Local llms aren’t super exciting unfortunately.
Neither are proprietary blackbox systems unfortunately.
Felt that. I already gave DeepSeek the HTML and it still said the UI was good to go, then told me it has no vision.
[dead]
What I've observed is that by prompting for longer I get to keep my brain focused on the architectural ideas (networking, protocols, data structures, etc) rather than worrying about the most performant/elegant implementations.
I always enjoyed writing code and I am very good at writing very performant and elegant code, but it would sometimes come at the detriment of focusing on the code and not the design.
because my manager will ping me and say "anon you aren't prompting enough" like they never heard of Goodhart's law before.
Write a script to make random prompts and use tokens. Not like they look at what you’re actually prompting.
No, don’t be silly, they get ai to spy on you en masse instead. Nobody has to look at anything anymore for it to be actionable.
Absolutely, have warned my juniors of this. Doesn't stop malicious compliance though, I can just prompt and burn tokens with source material from my assigned tickets for no reason perfectly fine.
I look at my colleagues' screens and they're prompting shit like 'restart this program' and 'is [service] running correctly'. I have below average prompt frequency because I know crazy shit like #!/bin/bash and ps aux. It's so goddamn insane.
And to top it all off, my token count is above the average, it's just the prompt count that is low. Got questioned about it earlier this week.
I tried hard to tokenmaxx one month and couldn’t do it as for most tasks, I’ve already figured out the solution while reading the ticket and vim/emacs-fu is more enjoyable than prompting and waiting. And for other tasks, I just knew the technology to do something with the least amount of effort.
[dead]
To be fair, I've been wanting to move to vim or emacs for a while now, but I've customized and gotten used to my current editor so much that it doesn't feel like a week's task.
[dead]
Seeing a lot of the same thing has helped me understand how people are getting the claimed 10x productivity.
[dead]
In my experience?
It used to be that one person had one to three codebases they knew intensely at my company. If you needed a bug in codebase X fixed, person Y was the one to do it and if they aren't available, person Z can do it, just not as quickly.
Now every person on my team has to handle tickets for every single codebase. There are about two dozen different large codebases involved here.
It's a ludicrous antipattern because person Y still needs to review the PR that person A generated for codebase X, and it will take them about as much time to wrangle the 2000 line PR (oh boy do LLMs love their mocks for unit tests) as it would have been for them to do the 50 line code change.
On top of that, it has "allowed" us to add feature after feature onto codebases not designed for them without refactoring. Is it good that this Flask API went from a purpose built service that interacted with the data analytics for product A stored in database X, and now our sales guys can sell product B, C, and D stored in database X? Uh, I'm sure it's great for them. Oh, and now it all can be stored in database X, Y, or Z depending on what the customer wants or what sales promised them. Great. Now I'm looking at a Flask app.py that's 12,000 lines of repeated code.
It has allowed poor designs to still produce working code. For a while. We seem to be getting a lot of bugs lately that look really bad to customers because it's for really simple shit. And I can't help but notice that happening to all the various products and sites I use too...
[dead]
Companies are tracking token usage across the board. You are in trouble for too less or too many. Unfortunately the token usage is the only measurable thing for most folks so everyone is playing the game, otherwise how else would Anthropic and OpenAI make the money
Writing code directly takes longer to warm up. Usually, I'd keep tens of thousands of lines in my head. In the past, I spent a lot of time designing error propagation and execution contexts. (Talented people might figure it out right away, but unfortunately I don't have that kind of talent.) So I'd have to think about things like Result<T> and how far to propagate errors—and worry about whether my approach would conflict with the existing codebase.
But these days, AI just generates code following the existing patterns of the codebase. In the past, staring at a blank screen meant going through a checklist of things to design—starting from policies and writing everything down step by step. Now, I just ask AI and it gives me a template—which is great. Then if the AI makes a mistake, I fix it manually.
Of course, I still hand-code sometimes—but only in the areas I enjoy. Most of the time, I use AI coding. Both are fun, and they complement each other in interesting ways. Doing both together is actually enjoyable.
For me, coding is either a flow state (when I have huge swaths of code to write) or deeply thinking about just a few lines (mostly to figure if I caught everything). The latter case is when I procrastinate the most, because I usually have an idea of a solution, but don’t want to do the work of actually verifying if it’s correct. Using AI then is skipping the enjoyable part (writing the code) to the unpleasant part (formulating hypothesis and verifying them).
I feel similarly, but at the same time, I think I am the exact opposite. I actually find formulating hypotheses more fun.
For hobby projects or things I start casually, I usually do not think about errors and such at all. When it is a tool I want to build or need for myself, I really do not care about that part.
In my case, I do not contribute to open source at all. Mostly, I deliver code for factory systems or specific companies, and usually, there are strict enterprise requirements. (To be precise, there is always that mandatory code the lead developer on their end dictates, right?) That kind of code is mostly no fun, but it has to meet their requirements and often clashes with my own style. Having AI write that code for me is a huge relief.
In that sense, I think it is just a difference in personality and preferences. I originally became a programmer because I wanted to make games. I started programming because I found it fascinating to see things drawn and displayed on the screen. Becoming a programmer was all because making Flash games was so much fun... So in that regard, for me, writing code is just 'drawing what I want on the screen', which is why I guess I do not mind if the code is written by AI.
When I contribute to other people's projects, I do not use AI for anything other than English translation, but for my own projects, I have no hesitation.
Is this really just a difference in inclination? It is not that I did not enjoy writing code, but rather that seeing what I want rendered on the screen brings me more joy.
When the concept of 'vibe coding' first came out, I really hated it (since my knowledge was earned over 4 to 5 years of getting scolded by lead developers as a subcontractor and factory software provider). But thinking about it, what I really wanted to do as a developer was just to build the worlds I envisioned, so I decided not to let it bother me too much.
We talk often here on HN, and I really enjoy debating with you. I learn a lot from you.Mr."skydhash", I actually remember you quite often, and I even steal a few keywords from your posts sometimes. Because we have different tendencies, we occasionally clash, but having these conversations is exactly what makes it enjoyable.
Thank you for always replying. Have a great day, and I hope this does not offend you in any way.
> Is this really just a difference in inclination? It is not that I did not enjoy writing code, but rather that seeing what I want rendered on the screen brings me more joy.
I've been tinkering with things since a very young age, started learning about computers in middle school and really started with programming in college (I had the basics since high school, but I was interested more in 3D modeling). So writing code is more like tinkering for me and I don't really particularly care about the result other than making it happen (correctly). Once it's done, it's no longer a subject of intellectual interest.
So the joy of creating a program is in the creation itself. Once it's done I merely use it (or maintain it if it's part of the work).
I don't condemn AI use, even when doing vibe coding. My main issue is with the hypers stating that it's ok to lower a codebase quality or encouraging recklessness (and the dubious anecdotes) in a collaborative settings. If you can ensure quality and collaborate easily with your colleagues, go ahead. If you can't, then you shouldn't send PRs around.
> Thank you for always replying. Have a great day, and I hope this does not offend you in any way.
Have a great day too. I always appreciate the different point of views on a subject. It's a big world and everyone has their own perspectives.
>If you can't, then you shouldn't send PRs around.
I think this is exactly why our differences emerge.
I rarely collaborate with colleagues. In contract delivery work, that is simply how things operate. Usually, after the architecture is divided into modules, I take on the role of implementing one entire area from start to finish. Because of this, I actually have almost no experience with direct code level collaboration.
While multiple developers typically share a single code base and constantly exchange PRs, I take full responsibility for the internal implementation within the designed I/O interfaces, which seems to be where our divergence stems from.
When the modules are finally integrated, it only becomes a matter of accountability. In that sense, aside from my own website, I might not actually be doing any sustainable development. To be honest, as you know if you try AI vibe coding, the AI's abstraction and my abstraction are different. Because I am not used to its structure, it is not easy for me to manually fix the code generated by AI. Even if I do fix it, I mostly just tweak the surface level. In that regard, I completely agree that there are valid concerns regarding long term maintenance. However, since meeting strict deadlines and ensuring the required behavior are more important to me than long term maintainability, I tend to be more lenient toward AI generation.
It seems we reached different conclusions because we operate in completely different domains. It is always fascinating to see how perspectives differ depending on the field when having these conversations. Have a nice day.
Although it has nothing to do with me, what a pleasure it was to read your comment.
> But these days, AI just generates code following the existing patterns of the codebase
Is this sarcasm?
I read these kinds of comments and wonder what makes reality so different for us. I personally have found AI has the easiest time in the world following existing patterns. At my workplace, our frontend code is so well organized most of the time all the AI has to do is copy and paste an implementation from somewhere else and change the names, and it gets right pretty much 100% of the time
Every workflow is highly personal, so there's no real reason to argue about it. Depending on the work, some tasks become patternized and others don't. Most people overestimate themselves as being near average, and some of them are actually unskilled. There's no point in fighting with them.
Even on HN, people don't comment purely out of 'rationality.'
I think AI generates well patterned code. Essentially, it handles a lot of situations with standardized code. But recognizing those patterns and knowing how to implement them are different things.
In programming, there are people who know how to implement something but can't explain the contract or the model behind it. For those people, AI might not be very useful, or they might be one of the rare few who write code far better than AI. Either way, the fact that an AI beat a top competitive programmer is enough to say it performs better than most people on HN. There's no point in arguing with them.
It's not that they're necessarily wrong. It's that they tend to generalize their own personal workflows.
AI can't do software engineering, but it can code well. Software engineering is the problem of transforming a complex open system into a closed one, taking a PM's requirements and building a single system out of them. AI can't do that. Why? Because AI can't adjust emphasis the way humans do. The design for frequently accessed parts and rarely accessed parts should be different, but AI treats everything uniformly, which makes it harder to modify later.
On the other hand, once a problem is closed and well defined, AI does much better than most people. It's logical and doesn't make the kind of leaps humans do, at least with frontier models. So there's no point in arguing with them at all.
Their experiences are based on their own workflows, so their perceptions naturally differ. And it's hard to tell whether they're saying it's bad because they truly understand it well, or because they don't understand it at all.
I'm not saying they should live in an echo chamber, but there's no reason to argue with them. It's better to trust statistical facts.
[dead]
Could be a symptom of which languages we use and which languages are in their training sets. I primarily write F#, which is a functional language that's compatible with the object-oriented C#. When AI tries to write code in my F# codebases, it almost always ignores the existing patterns/styles and tries to write it like an OO language. It has a weird desire to use mutability instead of the default immutability, for loops instead of pipes/monads, huge if/else blocks instead of pattern matching, etc. This is all very un-idiomatic for F#, not what a human programmer would write unless they were deliberately trying to write it like C#.
Maybe it's better in Fable/Sol, but it was a problem in Opus when I still used Claude, and it's still a problem with the Qwen and Deepseek models I use now. Either way, it seems to me that your code has to already conform to the patterns they want to write, or you're going to end up with new patterns.
To be fair, I do have to remind the AI to follow the codebase's conventions regularly and it is the #1 rule in our team's claude.md. And when I generate plans I ask that every new implementation follow a reference implementation. In your F# projects would something like that help or would it make no difference?
Yeah that's what I've ended up doing and it does help. I do have guidelines set up in my agents.md files, but they're hit or miss. It's best to just tell them directly to "write idiomatic F#," which they seem to understand.
It does so better the more "standard" the "existing patterns" are. :^)
[dead]
Like the Titan submarine team's moto mine is - real men test in production.
The LLM produce so much code that the best I can is skim and look for obvious flaws, also pass it trough adversarial one.
I spend 45 minutes writing it. then i git commit and move on cuz i made something good.
who is winning here? lol
[dead]
[dead]
[dead]
It could be. Or it could be 1x, or 0.2x. You don’t have enough information to make that judgment.
[dead]
Well you got me. I’d agree about that workflow, but something more rapid like a few seconds generating code and then a couple minutes reading it can be more engaging to me than writing it out yourself. I think it’s near time we all stop having such strong opinions about the matter either way personally.
[dead]
I’m entitled to my opinion about your opinion just like you’re entitled to your opinion about my opinion about your opinion.
[dead]
You make it sound like it’s a motivated opinion.
Yeah I kinda agree. The AI boosters have been super annoying for a while.
I’m not anywhere close to an AI booster but I find value in it. I think we should think of it less like some intelligent being or “agent” and more as a code generation tool. It would both be more productive and healthier.
[dead]
It’s worthwhile to me under specific conditions, mainly that the codebase has existing patterns and abstractions that the LLM utilizes, and they’re actually good. It’s not a common case but I’m lucky that one of the codebases I’m in is one I built myself mostly by hand, and LLMs are really effective in it at the moment. My main concern is making sure the generated code maintains the high standard, but it’s definitely saving me time.
I’ve kind of changed my mind on prompting, it’s definitely a skill. It’s a skill based on your own skills in the domain. I’m at the point where I can get the LLM to generate the same code (roughly speaking) that I would have written. So it’s basically generating the same thing I would write, just faster. So it’s like reading your own code. Using it as a crutch to do things you aren’t capable of is where people run into trouble. That’s where the massive amounts of code review come into play. For me, I’m only ever reviewing 100-300 loc changes at a time. Often less. Because I know what I’m doing and can break things down into manageable diffs.
Can’t see myself going back, but also can’t see myself doing it without the experience I have without LLMs. Which is a bit of an issue for new developers. Not sure what the solution is for that.
I’ve reached a similar conclusion, but there’s a part that worries me: the expertise that allows us to judge AI’s output was itself built by doing the work we’re now delegating. So there’s a risk that our judgement will decay over time. I’ve been thinking about the problem as choosing where we can afford to “borrow” comprehension, versus where we need to keep exercising it, and how to “claim back” the critical comprehension we lost.
A possible heuristic: Everywhere the LLM made a design decision is probably a place to revisit later. You can ship it now, but to stay in the game you need to stay in the loop.
If you need the LLM to explain to you the concept behind something - or even if you figure out yourself what it did - that's likely wrong and will lead to the undesirable outcomes you've mentioned.
As long as it just types and doesn't think otoh, you should be good. There is - I'd argue - little to no value in manually typing if (foo) {}. And it's also great for bouncing ideas around.
[dead]
That plus if you’ve ever stared at your code and then searched StackOverflow to see if you could find a better way of doing it, it’s like having that running continuously.
Yeah it’s great for prompting for improvements, granted you can actually judge the suggestions for yourself. They’re often slightly or majorly bad.
[dead]
this seems inappropriate. I think its a bad paradigm that just because you use a platform's service, they get intimate details about your usage. And for them to be so bold about publishing the statistics they've stolen from their customers data? Gives me a reason to never recommend my org use this platform.
The data is aggregated, and you cannot possibly identify a single user from what's been published. I see no issue here.
I think their point is that there's business value in the usage data and linear is using that value in a way that benefits them but not the customers they got it from.
It reminds me of matt levine's reframing of insider trading where it's not about fairness it's about theft. You're supposed to get secret insights and use them to get an edge. What you can't do is get an edge for yourself with secret insights that your employer got.
So it roughly comes down to "that data is valuable and rightfully belongs to the originating company." Which then makes this a contract diligence type situation.
My company uses Linear. The data presented in this blog post is worthless to me and the company. It can be crudely summarized as “agents and agentic development processes are conducting more Linear operations.” Duh!
Whether you make a good trade with the stolen information is spurious though.
I don't believe this very strongly. Again it's a contract issue not a moral one. But the metaphor still holds I think.
https://archive.is/rVwku - Matt Levine writing about insider trading
lol isn't this what google said and yet..the NSA cometh
I’d rather it was published for free in a blog post than sold without my knowledge. As a linear user. This shit doesn’t matter, everyone in the industry know these kinds of stats are being tracked, I’m happy for a company to be transparent about it.
Why would a company want to leak its processes and workflows to another company in a capitalist system. Seems sloppy and a short sighted transfer of wealth to external stockowners.
Uhh that's how a lot of economic data works too. Guess how we get a lot of jobs data... ADP
Oh hey! My industry. Guess what? ADP doesnt just yoink your data. ADP conducts voluntary surveys on the scale of hundreds of thousands. Voluntary. ADP also pays for it for the most part. Do you think Linear conducted..voluntary surveys here?
"Pull requests are up 111% in two years". Would be more honest to say that the number of pull requests "detected" by linear are up XXX%. Because it only works if you setup git repo tracking and use it properly. And at that point it is not obvious if more teams are using linear and using it correctly, or if the number of PR really increased that much!
Doubling PRs isn't necessarily unbelievable. AI reduces ceremony around PRs, makes the small shitty changes that you never had time to do possible and the larger cleanups at least doable.
Double the PRs doesn't mean double the output.
This looks like a "We are so AI native and efficient!!" article. At least, they could delve deeper into how they define the metrics and how they collected the data.
> delve
Butt-head: Huh huh huh. Hey Beavis, he said "delve". Huh huh huh.
Beavis: Yeah, I bet he'll use an em-dash next. Heh heh heh.
This is pretty interesting but I wish it would have been refined in two ways:
- The prose before the data appears to be AI generated. Not a big deal but it makes the reader work harder to figure out what's actually being said.
- Linear didn't control for their platforms AI changes over the past year. The platform has become much more AI integrated, so a lot of numbers will move. I'm not sure how you do it but this is only useful signal with a control.
> Time spent on customer requests, docs, and projects held steady [..] AI has so far changed how teams execute far more than how they decide what to build
I think the measurement for this may be flawed. We do mostly use AI to decide how to build. But what we build is influenced by AI-driven research into a problem or task. That's largely done in coding and desktop AI tools, not Linear Asks/AI.
I'm working on accelerating my team's work by implementing AI-driven code pipelines with guardrails to eliminate as much unnecessary review time as possible. Also making a chatbot for turning repetitive tasks & PRs into buttons, and an "architectural guidance" chatbot that gives advice tailored to our business, software/system architecture, cloud, standards, etc. This puts AI and automated jobs in the center of both how (automated task) and what (architecture guidance).
But this has a not-so-great implication for Linear. With my tools, a human never has to touch a ticket, so we could use any ticketing system with an API or CLI. Linear is a great product because they made a great interface. What happens when I replace their interface with a chat bot?
I think it's worth noting that headlines like "AI adoption has spread to every function" is only limited to roles covered/tracked by Linear.
Recent studies by e.g. Google show a much broader range of adoption.
Nice data!
Tim (author) if you're there: it'd be amazing to see the split of which agents people are using, if you have that data.
Founders topping the usage chart says more about org pressure than product value. Adoption driven from the top looks different from adoption driven by results.
I didn't know Linear has "AI features". Linear is boring, but that's actually fine by me.
I use LLMs to write my code, but this does not show up in this data.
The AI Slopologists strike again. More garbage by garbage people.
Is this just an opinion? If so, fair.
If it's an attempt at rebutting their claims etc, it'd be easier to interact if you provided some data, or concrete observations :)
The bullshit asymmetry principle suggests that once something is identified as bullshit, we shouldn't spend much time to write an excruciatingly detailed refutation.
Invoking the bullshit card on opposing views, in order not to have to elaborate your own pov, seems counterproductive, if the aim of your participation in a discussion is to test your own hypotheses about the world - or in any way gain or deliver insights.
Can't tell if you mean the people the article is talking about or the article itself
¿Por qué no los dos?
I might build a Chrome extension that looks for “AI” in HN submission titles and shows a fake comment at the start saying “AI is all slop garbage that’s total slop and I hate it. AI sucks and it’s slop!”
It will save people time reading the 5-10 other identical vacuous comments
[dead]
Rebuttal to what? I’m complaining that it’s a totally pointless comment that could be used on any AI related post. The comment just says “AI is slop garbage that sucks”.
What am I going to say to that? Obviously it can’t suck that badly or there wouldn’t be a large majority of programmers using it, plenty of famous programmers and developers of languages praising it, millions of people paying for $200 plans. It doesn’t need to be Carmack-level to get a massive amount of use out of it when you can just say “implement this chart here, give me some ideas on speeding up this algorithm, write a function that converts this heightmap to a .fbx” and it writes it.
[dead]
[dead]
[flagged]
[dead]
[flagged]
[flagged]
[dead]
[flagged]
[dead]