I usually agree with Simon but I think he is overlooking an important factor.
There is a lot of AI usage happening not because it shows benefits, but because the business has mandated its ubiquitous use. Companies having dashboards for token usage and rewarding people for using more tokens is a real thing. I just spoke with someone today who works at Microsoft and they are required to use AI for all of their work - they have to make a special request with justification if they decide not to use AI for even a single PR. This kind of demand isn't driven by value from either the company itself or from its workers; it is the kind of artificial demand you get from make-work projects to keep people employed during hard times.
We have to wait for the hype to settle down and people start making business decisions based on results before we can really value these AI products.
I think token leaderboards are idiotic, however… many companies are requiring AI use, with by far the most likely reason being that they truly believe AI-assisted development gets (or will after the time needed to get employees acclimated) better returns.
That mere belief by companies is not enough on its own to substantiate durable market fit. Companies believe all kinds of silly things. We're looking for long-term trends, and the returns have to be real for AI development to be more than a dream companies will eventually wake up from.
I strongly disagree. I'm an engineer - I'm all about the fastest, cheapest thing that meets the requirements. I don't need Opus 4.7, even for my complex programming tasks. It costs over 10x other models available that still give good enough answers. Those smaller models are also a lot faster to output tokens, which saves me time.
Once the model gets good enough, the returns on bigger models diminishes quickly. I don't want to spend 10x the money and wait 5x the time to get answers that are equivalent.
I use composer-2 daily for complex programming tasks. It's a fine tuned Kimi 2.5 - nothing groundbreaking. I've even had reasonable success using Qwen 3.5 on my desktop GPU. Opus might be better, but it's certainly not necessary to get good results.
Every meeting, every memo, and every prototype is output in terms of the employees doing that work. Whether it's directly saleable is irrelevant. The investors base the value of their investment on the expected future value of the company, but the people being to do the work are being paid for the work they are doing regardless of what the future value of the company becomes. That is if they are paid a salary. If they are given shares, then that compensation is entirely dependent on future value.
Cursor with its tab completion. Iterate with the agent part to research, design, and plan. Let it generate boilerplate and scaffolding, perhaps with placeholders for you to fill in. Then fill in as you normally would, but with an auto-complete that uses all of your code and design docs and everything else to inform that completion rather than the limited set of info that shows up in an LSP.
I believe JetBrains IDEs have something similar too, but I don't have as much experience using theirs since my employer hasn't blessed their AI tools yet.
I think we can do both. Ask the AI to summarize it, but to show examples and point out where things happen. Let it make you a Coles Notes. You still need to look at the code yourself and understand it, but an initial outline and explanation can really jump start the process and save a lot of time. Likewise, it's hard to find a bug and come up with a fix, but those same things are often oblivious in hindsight. Once we have an idea of what the bug is, we can often look at the code directly or write tests to confirm in a fraction of the time it took to discover in the first place. Once we have an idea for a fix with code and an explanation for how it fixes the bug, we can often review that explanation, think through any implications, and test the fix in a fraction of the time it takes to come up with it in the first place.
I'm happy to let the AI explore possibilities for me, eliminating the search problem. It's still on me to understand the solution, verify it works, and handle any other considerations I know of that the AI wouldn't. It gives me the insight, but I'm responsible for the final solution.
I'm always hesitant of these claims. Sure, it's possible that AI really did help them achieve the same level of quality at 100x the pace. It's also possible it generated a huge tech debt that only passes the tests but hasn't planned for future maintainability, readability, and extensibility, and a year from now their entire process will grind to a halt.
I have a few people on my team who move 5-10x faster than others in writing code. They also generate 5-10x as many bugs and require that much more rework in the things that were shipped. They move fast and break things. Their code is almost malicious compliance in that it passes the tests or spec as given, while leaving glaring holes in things that weren't fully specified. A more careful developer would have asked questions, considered alternatives, and looked for ways to leverage existing solutions or plan for future work, but that takes time now and its benefits don't show up until later.
So while I don't immediately disbelieve that 10x+ speedups are possible with heavily AI-augmented flows, I am skeptical of any short term success stories until we have time to see the long term effects. We already know that cutting corners can save time in the short term only to cost us several times more in the long term.
Great point! This is along the same lines as a low fidelity prototype. It doesn't have to be production quality - hell, it barely needs to work so long as it's good enough to get feedback. Now I can have higher fidelity prototypes in the same time or more iterations in the same time, either of which tend to give me more insight and get me closer to the solution faster. Even if I never ship a line of AI-generated code, I can use it to write the same throw away code I did before, but much faster.
I treat it like other triage tasks: things could always be better, but how much effort does it take and how much better could it be?
There's a common saying that the enemy of good is perfect. It's easy to get stuck in the loop of endlessly polishing something but never actually releasing it, even without AI. It's on us to decide how good is good enough and when to stop.
Over time I've learned to be rather aggressive about cutting out work. I'll quickly ask myself how serious is the issue (does it give wrong answers? block important flows? look embarrassing? or is it just a minor annoyance?) and how much effort would it take (five minutes? two hours? three weeks?). I should be able to make that call in no more than 30 seconds. I skim through the list of 20 suggestions the AI gives, I make plans to iterate on the 3 that are serious, and I simply accept that the rest are "good enough". It's not easy - both to be willing to let issues stand and to make the decision about what is good enough - but it's an important part of the job when triaging lists of bug reports and feature requests, so it's something we need to get good at anyway.
reply