Rendered at 16:27:50 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
cmiles8 6 hours ago [-]
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.
blfr 6 hours ago [-]
> 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.
cmiles8 4 hours ago [-]
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.
stuartjohnson12 3 hours ago [-]
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.
cmiles8 2 hours ago [-]
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.
Majromax 2 hours ago [-]
> 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.
kyllo 2 hours ago [-]
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.
Majromax 2 hours ago [-]
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.
porridgeraisin 2 hours ago [-]
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.
danggggg 5 hours ago [-]
[dead]
blfr 4 hours ago [-]
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.
4 hours ago [-]
danggggg 6 hours ago [-]
[dead]
inigyou 4 hours ago [-]
Considering many of them are starting from an existing product and making it worse, they're -10x
danggggg 4 hours ago [-]
[dead]
drodgers 6 hours ago [-]
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.
rfgplk 2 hours ago [-]
> 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.
duskdozer 5 hours ago [-]
Is this mean-spirited comment really what you want to share as the face of your company?
chasd00 4 hours ago [-]
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.
danggggg 4 hours ago [-]
[dead]
jappgar 4 hours ago [-]
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.
inigyou 4 hours ago [-]
This but the train is competence (the opposite of AI) and it has already left.
qsera 4 hours ago [-]
The AI whisperer! The hottest job title of 2026!
bluecalm 5 hours ago [-]
>> 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.
inigyou 4 hours ago [-]
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.
chasd00 4 hours ago [-]
> 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.
danggggg 6 hours ago [-]
[dead]
drodgers 5 hours ago [-]
> 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.
inigyou 4 hours ago [-]
Care to share your costs and revenues then?
danggggg 4 hours ago [-]
[dead]
danggggg 5 hours ago [-]
[dead]
gkamal 15 hours ago [-]
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:-) )
onion2k 11 hours ago [-]
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.
hexasquid 12 hours ago [-]
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.
onion2k 11 hours ago [-]
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.
Fordec 11 hours ago [-]
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
jolaflow 6 hours ago [-]
[dead]
AlexKalWork 8 hours ago [-]
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.
bitwize 53 minutes ago [-]
> 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.
sebiandev 13 hours ago [-]
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.
clintonb 12 hours ago [-]
The data is aggregated, and you cannot possibly identify a single user from what's been published. I see no issue here.
giraffe_lady 11 hours ago [-]
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!
whateveracct 11 hours ago [-]
lol isn't this what google said and yet..the NSA cometh
anon7000 10 hours ago [-]
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.
rightbyte 8 hours ago [-]
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.
humbleharbinger 13 hours ago [-]
Uhh that's how a lot of economic data works too. Guess how we get a lot of jobs data... ADP
sebiandev 13 hours ago [-]
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?
jmtulloss 10 hours ago [-]
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.
hobofan 10 hours ago [-]
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.
jdw64 17 hours ago [-]
These days, my work has become: generate code for 20 minutes, then spend an hour reading it.
tankaiji 16 hours ago [-]
And then more hours cleaning it up and re-prompting.
nik282000 13 hours ago [-]
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.
nightmunnas 8 hours ago [-]
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.
Frost1x 6 hours ago [-]
You don’t even have to go that far, recent Opus models are quite impressive.
anon7000 10 hours ago [-]
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.)
lukebitts 4 hours ago [-]
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
hypfer 10 hours ago [-]
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.
wongarsu 5 hours ago [-]
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)
hypfer 5 hours ago [-]
> 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.
wongarsu 3 hours ago [-]
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
lukebitts 4 hours ago [-]
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
prolly97 8 hours ago [-]
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.
hypfer 8 hours ago [-]
"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.
tuyiown 7 hours ago [-]
> 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.
jolaflow 6 hours ago [-]
[flagged]
hypfer 6 hours ago [-]
Do you people ever think of anything else other than pitching your next SaaS startup thing?
Holy crap. Does your home have mirrors?
jolaflow 5 hours ago [-]
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.
Try using Fable and report back. Local LLM is to Fable as Little Tike car is to a Porsche.
TingPing 12 hours ago [-]
Local llms aren’t super exciting unfortunately.
duskdozer 4 hours ago [-]
Neither are proprietary blackbox systems unfortunately.
viccis 12 hours ago [-]
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.
johnxianren 12 hours ago [-]
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.
danggggg 16 hours ago [-]
[dead]
conradludgate 12 hours ago [-]
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.
denkmoon 16 hours ago [-]
because my manager will ping me and say "anon you aren't prompting enough" like they never heard of Goodhart's law before.
what 13 hours ago [-]
Write a script to make random prompts and use tokens. Not like they look at what you’re actually prompting.
monkpit 12 hours ago [-]
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.
denkmoon 11 hours ago [-]
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.
duskdozer 4 hours ago [-]
Seeing a lot of the same thing has helped me understand how people are getting the claimed 10x productivity.
skydhash 6 hours ago [-]
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.
danggggg 5 hours ago [-]
[dead]
duskdozer 4 hours ago [-]
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.
danggggg 4 hours ago [-]
[dead]
danggggg 6 hours ago [-]
[dead]
viccis 12 hours ago [-]
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...
10 hours ago [-]
danggggg 6 hours ago [-]
[dead]
sandeepkd 12 hours ago [-]
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
jdw64 16 hours ago [-]
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.
nozzlegear 13 hours ago [-]
> But these days, AI just generates code following the existing patterns of the codebase
Is this sarcasm?
lukebitts 4 hours ago [-]
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
nozzlegear 2 hours ago [-]
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.
lukebitts 41 minutes ago [-]
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?
jdw64 4 hours ago [-]
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.
danggggg 3 hours ago [-]
[dead]
hypfer 10 hours ago [-]
It does so better the more "standard" the "existing patterns" are. :^)
danggggg 6 hours ago [-]
[dead]
skydhash 16 hours ago [-]
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).
jdw64 15 hours ago [-]
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.
Calamity 13 hours ago [-]
Although it has nothing to do with me, what a pleasure it was to read your comment.
skydhash 14 hours ago [-]
> 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.
jdw64 14 hours ago [-]
>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.
ReptileMan 8 hours ago [-]
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.
whateveracct 11 hours ago [-]
I spend 45 minutes writing it. then i git commit and move on cuz i made something good.
who is winning here? lol
danggggg 6 hours ago [-]
[dead]
mulanroo 14 hours ago [-]
[dead]
danggggg 16 hours ago [-]
[dead]
dullcrisp 16 hours ago [-]
It could be. Or it could be 1x, or 0.2x. You don’t have enough information to make that judgment.
danggggg 16 hours ago [-]
[dead]
dullcrisp 16 hours ago [-]
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.
danggggg 16 hours ago [-]
[dead]
dullcrisp 16 hours ago [-]
I’m entitled to my opinion about your opinion just like you’re entitled to your opinion about my opinion about your opinion.
danggggg 16 hours ago [-]
[dead]
dullcrisp 14 hours ago [-]
You make it sound like it’s a motivated opinion.
slopinthebag 13 hours ago [-]
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.
danggggg 6 hours ago [-]
[dead]
slopinthebag 16 hours ago [-]
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.
deimos_28 10 hours ago [-]
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.
hypfer 10 hours ago [-]
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.
danggggg 6 hours ago [-]
[dead]
dullcrisp 16 hours ago [-]
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.
slopinthebag 13 hours ago [-]
Yeah it’s great for prompting for improvements, granted you can actually judge the suggestions for yourself. They’re often slightly or majorly bad.
danggggg 6 hours ago [-]
[dead]
cadamsdotcom 10 hours ago [-]
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.
agnishom 13 hours ago [-]
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.
greatgib 16 hours ago [-]
"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!
well_ackshually 6 hours ago [-]
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.
0xbadcafebee 16 hours ago [-]
> 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?
slopsosn 14 hours ago [-]
The AI Slopologists strike again. More garbage by garbage people.
prolly97 8 hours ago [-]
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 :)
inigyou 4 hours ago [-]
The bullshit asymmetry principle suggests that once something is identified as bullshit, we shouldn't spend much time to write an excruciatingly detailed refutation.
subarctic 14 hours ago [-]
Can't tell if you mean the people the article is talking about or the article itself
what 13 hours ago [-]
¿Por qué no los dos?
joegibbs 6 hours ago [-]
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
danggggg 6 hours ago [-]
[dead]
joegibbs 6 hours ago [-]
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:-) )
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.
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.
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.
Skill/Hook usage rates, budget spend, auto-approval rate, focus area heatmaps, MTTR, MTTD are all there now
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.
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.
- 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.
Recent studies by e.g. Google show a much broader range of adoption.
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.
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
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.
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)
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.
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
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.
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.
Holy crap. Does your home have mirrors?
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
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.
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.
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...
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.
Is this sarcasm?
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.
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.
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.
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.
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.
The LLM produce so much code that the best I can is skim and look for obvious flaws, also pass it trough adversarial one.
who is winning here? lol
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.
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.
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.
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.
I use LLMs to write my code, but this does not show up in this data.
Double the PRs doesn't mean double the output.
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?
If it's an attempt at rebutting their claims etc, it'd be easier to interact if you provided some data, or concrete observations :)
It will save people time reading the 5-10 other identical vacuous comments
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.