I'm not.
I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the good parts.
I liken AI development to a developer somewhere between junior and mid-level, someone I can given a paragraph or two of thought out instructions and have them bang out an hour of work. (The potential for then stunting the growth of actual juniors into tomorrow's senior developers is a serious concern, but a separate problem to solve)
In some cases, especially with the more senior devs in my org, fear of the good parts is why they're against AI. Devs often want the inherent safety of the boring, easy stuff for a while. AI changes the job to be a constant struggle with hard problems. That isn't necessarily a good thing. If you're actually senior by virtue of time rather than skill, you can only take on a limited number of challenging things one after another before you get exhausted.
Companies need to realise that AI to go faster is great, but there's still a cognitive impact on the people. A little respite from the hardcore stuff is genuinely useful sometimes. Taking all of that away will be bad for people.
That said, some devs hate the boring easy bits and will thrive. As with everything, individuals need to be managed as individuals.
That looks like plenty of hours of fun! Thanks for the link :)
There's also the fact that, while you're coding the easy stuff, your mind is thinking about the hard stuff, looking things up, seeing how they articulate. If you're spending 100% of your time on hard stuff, you might be hurting these preliminaries.
I know brilliant people who took up knitting to keep their hands busy while they think over their difficult problems. But that only works if you can knit in your work hours. Sadly, despite clearly improving the productivity of these people, this is a fireable offense in many jobs.
I'm not saying that the only way to think through a hard problem is to work on boilerplate. If you are in a workplace where you can knit, or play table soccer, by all means, and if these help you, by all means, go for it.
What I'm thinking out loud is that if we're dedicating 100% of our time to the hard problems, we'll hit a snag, and that boilerplate may (accidentally) serve as the padding that makes sure we're not at these 100%.
That being said, I'm not going to claim this as a certainty, just an idea.
Part of the problem is that in big orgs, you need to show consistent progress in order to not get put on some PIP and kicked out of the company. There are performance review cycles and you have to show something continuously.
That ONLY works if you have boring, easy work. It's easy to deliver consistent progress on that.
Interesting and difficult work is nice only if you are trusted to try your best and given the freedom to fail. That's the nature of hard problems; progress in those domains is very sudden and Poissonian and not consistent by nature. If you're going to be judged on your ability to be sub-Poissonian and consistent, and get put on a PIP for not succeeding at it one review cycle (and possibly risking income that you use to put a roof over your head or feed your family) it's not worth the career risk to try difficult things.
Not saying this is the way I think, it's just the reality of how things often work in big orgs, and one of the reasons I dislike many big orgs.
That's matches my experience. In my first job, every time a new webapp project has been starting it was fun. Not because of challenges or design, but simply because of the trivial stuff done for n-th time - user accounts, login, password reset, admin panel. Probably should have been automated at this point, but we got away with reinventing the wheel each time.
I find this hilarious. From what I've seen watching people do it, it changes the job from deep thought and figuring out a good design to pulling a lever on a slot machine and hoping something good pops out.
The studies that show diminished critical thinking have matched what i saw anecdotally pairing with people who vibe coded. It replaced deep critical thinking with a kind of faith based gambler's mentality ("maybe if i tell it to think really hard it'll do it right next time...").
The only times ive seen a notable productivity improvement is when it was something not novel that didnt particularly matter if what popped out was shit - e.g. a proof of concept, ad hoc app, something that would naturally either work or fail obviously, etc. The buzz people get from these gamblers' highs when it works seems to make them happier than if they didnt use it at all though.
To pair this with the comment you're responding to, the decline in critical thinking is probably a sign that there's many who aren't as senior as their paycheck suggests. AI will likely lead to us being able to differentiate between who the architects/artisans are, and who the assembly line workers are. Like I said, that's not a new problem, it's just that AI lays that truth bare. That will have an effect generation over generation, but that's been the story of progress in pretty much every industry for time eternal.
Is it really? Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction. I've seen people describing things as sludge, but they've never learned awk to write a simple script to take care of the work. Or learned how to use their editor, instead using the same pattern they would have with Notepad.
I think it's better to take a step back and reflect on why we're spending time on basic stuff instead. Instead of praying that the LLM will generate some good basic stuff.
Put differently, I go back to my original comment, where AI is essentially a junior/mid dev that you can express what needs to be done with enough detail. In either case, AI or dev, you'd review and/or verify it.
> Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction.
One could say the same of installing packages in most modern programming languages instead of writing the code from first principles.
I disagree, because libraries define an interface with (ideally) precise, reproducible semantics, that you make use of. They provide exactly what the grandparent is saying, namely a formal abstraction. When you have the choice between a library and an LLM, requiring equal effort, the library is clearly preferable.
When an LLM is more time-efficient at a given coding task, it can be taken as an indication of a lack of a suitable library, tooling, or other abstraction for the use case.
Ive never found this to be true once in my career.
I know a lot of devs who looked down on CRUD or whatever it was they were doing and produced boilerplate slop though.
Code isnt like pottery. There arent "artisanal" devs who produce lovely code for people to look at like it's a beautiful vase. Good code that is hooked into the right product-market fit can reach millions of people if it works well.
The world was replete with shitty code before AI and mostly it either got tossed away or it incurred epic and unnecessary maintenance costs because it actually did something useful. Nothing has changed on that front except the tsunami of shit got bigger.
1) you try to explain what you want to get done
2) you try to explain what you want to get done and how to get it done
The first one is gambling, the second one has very small failure rate, at worst, the plan it presents shows it's not getting the solution you want it to do.
Very true. I think AI (especially Claude Code) forced me to actually think hard about the problem at hand before implementing the solution. And more importantly, write down my thoughts before they fleet away from my feeble mind. A discipline that I wished I had before.
These days the only difference is that I feed my ideas to a few different LLMs to have "different opinions". Usually they're crap but sometimes they present something useful that I can implement.
Monitoring AI output on any task is high arousal, low satisfaction, unless you're constantly prompting for quick wins.
On the flip side, there have been lots of times where I personally didn’t have a lot of time to deeply research a topic (read papers, build prototypes of different ideas, etc) due to lack of time and resources. If all of the boring stuff is gone, and building prototypes is also 3x faster maybe what will end up happening is we can now use all of this free time to try lots of different ideas because the cost of exploration has been lowered.
I disagree that this has anything to do with people needing a break. All code eventually has to be reviewed. Regardless of who or what wrote it, writing too much of it is the problem. It's also worth considering how much more code could be eliminated if the business more critically planned what they think they want.
These tensions have existed even before computers and in all professions.
The ones who are excited about this are the ones who are motivated by the product. When AI can whip up some half-baked solution it sure looks like you can focus on the product and "get someone to code it up for you". But unless it's a well-understood and previously executed solution, you're going to run into actual technical problems and have to fix them. But your motivation to deal with the irritating pedantrics of the modern computing stack (which are the same as all technology ever, with orders of magnitude more parts) hasn't been built up. There's no beneficial flywheel, just a fleet of the Sorceror's Apprentice mindless brooms that you hope you can get work enough to ship.
The issue of senior-juniors has always been a problem; AI simply means they're losing their hiding spots.
AI has also been a really good brainstorming partner - especially if you prompt it to disable sycophancy. It will tell you straight up when you are over-engineering something.
It's also wonderful at debugging.
So I just talk to my computer, brainstorm architectures and approaches, create a spec, then let it implement it. If it was a bad idea, we iterate. The iteration loop is so fast that it doesn't matter.
Did you end up regretting a design choice, but normally you'd live with it because so much code would have to be changed? Not with Agentic coding tools - they are great at implementing changes throughout the entire codebase.
And its so easy to branch out to technologies you're not an expert in, and still be really effective as you gain that expertise.
I honestly couldn't be happier than I am right now. And the tools get better every week, sometimes a couple times a week.
Can you share more about how you are prompting to disable sycophancy?
I'm in the same boat (granted, 10 years less) but can't really relate with this. By the time any part becomes boring, I start to automate/generalize it, which is very challenging to do well. That leaves me so little boring work that I speed run through it faster by typing it myself than I could prompt it.
The parts in the middle – non-trivial but not big picture – in my experience are the parts where writing the code myself constantly uncovers better ways to improve both the big picture and the automation/generalization. Because of that, there are almost no lines of code that I write that I feel I want to offload. Almost every line of code either improves the future of the software or my skills as a developer.
But perhaps I've been lucky enough to work in the same place for long. If I couldn't bring my code with me and had to constantly start from scratch, I might have a different opinion.
The two aren't mutually exclusive. You can use AI to build your tooling. (Unless it's of sufficient complexity or value that you need to do the work yourself)
I've struggled heavily trying to figure out how to get it to write the exactly correct 10 lines of code that I need for a particularly niche problem, and so I've kind of given up on that, but getting it to write the 100 lines of code around those magic 10 lines saves me so much trouble, and opens me up to so many more projects.
I find it best as a "personal assistant," that I can use to give me information -sometimes, highly focused- at a moment's notice.
> The potential for then stunting the growth of actual juniors into tomorrow's senior developers is a serious concern
I think it's a very real problem. I am watching young folks being frozen out of the industry, at the very beginning of their careers. It is pretty awful.
I suspect that the executives know that AI isn't yet ready to replace senior-levels, but they are confident that it will, soon, so they aren't concerned that there aren't any more seniors being crafted from youngsters.
Would suck, if they bet wrong, though…
My life quality (as a startup cofounder wearing many different hats across the whole stack) would drop significantly if Cursor-like tools [1] were taken away from me, because it takes me a lot of mental effort to push myself to do the boring task, which leads to procrastination, which leads to delays, which leads to frustration. Being able to offload such tasks to AI is incredibly valuable, and since I've been in this space from "day 1", I think I have a very good grasp on what type of task I can trust it to do correctly. Here are some examples:
- Add logging throughout some code
- Turn a set of function calls that have gotten too deep into a nice class with clean interfaces
- Build a Streamlit dashboard that shows some basic stats from some table in the database
- Rewrite this LLM prompt to fix any typos and inconsistencies - yeah, "compiling" English instructions into English code also works great!
- Write all the "create index" lines for this SQL table, so that <insert a bunch of search usecases> perform well.
[1] I'm actually currently back to Copilot Chat, but it doesn't really matter that much.
That's one of the thing that I wouldn't delegate to LLM. Logging is like a report of things that happens. And just like a report, I need relevant information and the most useful information.
...
A lot of these use cases actually describes the what. But the most important questions is always the why. Why is it important to you? Or to the user? That's when things have a purpose and not be just toys.
As to why, it's because I'm building an app with a growing userbase and need to accommodate to their requirements and build new features to stay ahead of the competition. Why you decided I'm describing a toy project is beyond me.
The reason senior engineers are being paid that well is not because they need to type a lot of code to get new features in. It's because they need to figure how to have less code while having more features.
However. There's also good news. AI is also an amazing tool for learning.
So what I see AI doing is simply separating people who want to put effort forth and those who don't.
Absolutely. For example, I've been learning Autodesk Fusion, and after establishing a small foundation through traditional learning techniques, I've been able to turbocharge my learning by asking precise questions to AI.
I image this really sucks for those whose business model relied on gatekeeping knowledge. (like training companies)
If you aren't talented enough to write or record your own music, you aren't really a musician.
If you have a quick question about music theory and you want a quick answer, AI can be a benefit.
This is where AI actually helps - you have a very precise vision of what you want, but perhaps you've forgotten about the specific names of certain API methods, etc. Maybe you don't want to implement all the cases by hand. Often validating the output can take just seconds when you know what it is you're looking for.
The other part of making the output do what you want is the ability to write a prompt that captures the most essential constraints of your vision. I've noticed the ability to write and articulate ideas well in natural language terms is the actual bottleneck for most developers. It takes just as much practice communicating your ideas as it does anything else to get good at it.
The problem is that junior developers are what we make senior developers with— so in 15 years, this is going to be yet another thing that the US used to be really good at, but is no longer capable of doing, just like many important trades in manufacturing. The manufacturers were all only concerned with their own immediate profit and made the basic sustainability of their workforce, let alone the health of the trades that supported their industries, a problem for everyone else to take care of. Well, everyone else did the same thing.
In 15 years senior developers will not be needed as well. Anyway no company is obliged to worry about 15 years timescale
Most people don’t share your confidence that we will replace senior engineers and I’d gobsmacked if we could. Just like the magical ‘automation’ can’t replace the people that actually make the physical things that the machines use to do their jobs, or fix the machines, no matter how good it gets. But the quantitatively-minded MBAs just kept kicking the can down the road and assumed it was someone else’s problem that the end of the road was approaching. It wasn’t their problem that there would be a problem in 30 years, and then it wasn’t their problem when it was 10 years, and now that we’re standing at the edge of a cliff, they’re realizing that it’s everybody’s problem and it’s going to be a hell of a lot more painful than if they’d had an extremely modest amount of foresight.
Now, US manufacturers are realizing that all of their skilled laborers are retiring or dying, and there isn’t enough time to transfer the more complex knowledge sets, like Tool and Die making, to a new set of apprentices. Many of these jobs are critical not only to national security, but also our country’s GDP because the things we do actually make are very useful, very specialized, and very expensive. Outsourcing jobs like making parts for fighter jets is really something we don’t want shipped overseas unless we want to see those parts pop up on aliexpress. If nobody is responsible for it and nobody wants to fund the government to fix it, but it is a real problem, it doesn’t take a genius to see the disconnect there.
I love AI and use it for both personal and work tasks for two reasons:
1. It's a way to bounce around ideas without (as much) bias as a human. This is indispensable because it gives you a fast feedback mechanism and validates a path.
2. It saves me typing and time. I give it one-shot, "basic work" to do and it's able to do accomplish at least 80% of what I'd say is complete. Although it may not be 100% it's still a net positive given the amount of time it saves me.
It's not lost on me that I'm effectively being trained to always add guardrails, be very specific about the instructions, and always check the work of AI.
Shhh, WIP blog post (on webpipe powered blog)
https://williamcotton.com/articles/introducing-web-pipe
Yes, I wrote my own DSL, complete with BDD testing framework, to write my blog with. In Rust!
GET /hello/:world
|> jq: `{ world: .params.world }`
|> handlebars: `<p>hello, {{world}}</p>`
describe "hello, world"
it "calls the route"
when calling GET /hello/world
then status is 200
and output equals `<p>hello, world</p>`
I expect that in a year my relationship with AI will be more like a TL working mostly at the requirements and task definition layer managing the work of several agents across parallel workstreams. I expect new development toolchains to start reflecting this too with less emphasis on IDEs and more emphasis on efficient task and project management.
I think the "missed growth" of junior devs is overblown though. Did the widespread adoption of higher-level really hurt the careers of developers missing out on the days when we had to do explicit memory management? We're just shifting the skillset and removing the unnecessary overhead. We could argue endlessly about technical depth being important, but in my experience this hasn't ever been truly necessary to succeed in your career. We'll mitigate these issues the same way we do with higher-level languages - by first focusing on the properties and invariants of the solutions outside-in.
I actually think this is one skill LLMs _do_ train, albeit for an entirely different reason. Claude is fairly bad at considering edge cases in my experience, so I generally have to prompt for them specifically.
Even for entirely “vibe-coded” apps I could theoretically have created without knowing any programming syntax, I was successful only because I knew about possible edge cases.
Analogies to humans don't work that well. AI is super-human in some respects while also lacking the ability to continually work toward a goal over long periods of time. AI can do very little on its own - just short / scoped / supervised tasks.
However, sometimes the situation is reversed, AI is the teacher who provides some examples on how to do things or provides hints on how to explore a new area and knows how others have approached similar things. Then, sometimes, AI is an astute code reviewer, typically providing valuable feedback.
Anyway, I've stopped trying anthropomorphize AI and simply try to reason about it based on working with it. That means combinations of direct ChatGPT usage with copy / paste / amend type workflows, async style / full PR style usage, one-shot "hail Mary" type throw away PRs just to establish an initial direction as well as PR reviews of my own code. I'm using AI all the time, but never anything like how I would work with another human.
But the issue is some of that speedrunning sometimes takes so much time, it becomes inefficient. It's slowly improving (gpt5 is incredible), but sometimes it get stuck on really mundane issue, and regress endlessly unless I intervene. And I am talking about straightforwars functional code.
I think you’re the best case support for AI coding. You know clearly what you want, so you know clearly what you don’t want. So if you had decent verbal dexterity you could prompt the AI model and manage to accomplish what you intended.
A lot of programming problems / programmer contexts don’t match that situation. Which is the problem with universalizing the potency of AI / benefits of AI coding.
the laziness manifest itself into productivity as crazy as this sounds. how? lazy people find a way to automate repetitive tasks. what I have learned from these over the years is that anything you do twice has to find a way to be automated as third time is around the corner :)
what does this have to do with AI? the AI has taken automation to another level allowing us to automate so much of our work that was not previously possible. I found myriad of ways to use AI and several of my best (lazy) co-workers have as well. I cannot imagine doing my work anymore without it, not because of any “magic” but because my lazy ass will be able to do all the things that I have automated out
This persona driven workflow is so weird to me. Feels like stuck in old ways.
It's what is, to me, so bizarre about the present moment: certainly investment is exceptionally high in AI (and of course use), but the dominant position in the media is precisely such a strange 'anti-AI hype' that positions itself as a brave minority position. Obviously, OpenAI/Altman have made some unfortunate statements in self-promotion, but otherwise I genuinely can't think of something I've read that expresses the position attacked by the anti-AI-ers -- even talk of 'AGI' etc comes from the AI-critical camp.
In a sense, the world seems divided into three: obvious self-promotion from AI companies that nobody takes seriously, ever-increasingly fervent 'AI critique', and the people who, mostly silent, have found modern AI with all its warts to be an incomparably useful tool across various dimensions of their life and work. I hope the third camp becomes more vocal so that open conversations about the ways people have found AI to be useful or not can be the norm not the exception.
Why the insistence on anthropomorphizing what is just a tool? It has no agency, does not 'think' in any meaningful manner, it is just pattern matching on a vast corpus of training data. That's not to say it can't be very useful - as you seem to have found - but it is still just a tool.
Not really though can it, unless that codebase and Jira happens to pattern match correctly somewhere.
I'd say that the difference is just that LLMs have a natural language interface (for good or for ill).
Geohot is easily a 99.999 percentile developer, and yet he can’t seem to reconcile that the other 99.999 percent are doing something much more basic than he can ever comprehend.
It’s some kind of expert paradox, if everyone was as smart and capable as the experts, then they wouldn’t be experts.
I have come across many developers that behave like the AI. Can’t explain codebases they’ve built, can’t maintain consistency.
It’s like a aerospace engineer not believing that the person that designs the toys in an Kinder egg doesn’t know how fluid sims work.
I’m surprised to see this. From my perspective, reading comments and seeing which posts rise to the top, HN as a whole seems pretty bullish on the tech as whole…
HN participants (generally speaking) are against: AI, Crypto, HFT. I've worked in 2/3 of these industries so have first hand experience. My basic summary is that the average commenter here has a lot of misinformation on these topics (as a insider).
But don't worry. The company puts them somewhere they can't do any damage. Most of them become managers.
> The only reason it works for many common programming workflows is because they are common. The minute you try to do new things, you need to be as verbose as the underlying language.
I've actually seen another developer that was probably in the same category write his own self-driving software. It kind of worked, but couldn't have ever been production ready, so it was just an exercise in flexing without any practical application.
So, what product that George built do you actually use?
Yes, because I've seen them build software that was actually used. And I've seen a few that did just like him, impressive sounding projects that had no usage.
I understand it's something subjective. I get the same feeling when looking at Damien Hirst's monstrouly expensive stuff that leaves me cold. Even after I get the concepts behind the works, my end feeling is of "so what?".
Why did you feel the need to say that?
Geohot live streamed himself broadcasting a transaction from scratch.
For that I respect his level of knowledge. Plus he built comma which is a product I use almost everyday.
Really?
"The best model of a programming AI is a compiler... You give it a prompt, which is “the code”, and it outputs a compiled version of that code. Sometimes you’ll use it interactively, giving updates to the prompt after it has returned code, but you find that, like most IDEs, this doesn’t work all that well and you are often better off adjusting the original prompt and “recompiling”."
Really?
If you do not understand his point, you need to read more about our field.
I think his excellency in his own trade limited his vision for the 99% who just want to get by in the job. How many dev even deal with compiler directly these days? They write some code, fix some red underlines, then push, pray and wait for pipeline pass. LLMs will be gods in this process, and you can even beg another one if your current one does not work best.
First, the assertion that the best model of "AI coding" is that it is a compiler. Compilers deterministically map a formal language to another under a spec. LLM coding tools are search-based program synthesizers that retrieve, generate, and iteratively edit code under constraints (tests/types/linters/CI). That’s why they can fix issues end-to-end on real repos (e.g., SWE-bench Verified), something a compiler doesn’t do. Benchmarks now show top agents/models resolving large fractions of real GitHub issues, which is evidence of synthesis + tool use, not compilation.
Second, that the "programming language is English". Serious workflows aren’t "just English." They use repo context, unit tests, typed APIs, JSON/function-calling schemas, diffs, and editor tools. The "prompt" is often code + tests + spec, with English as glue. The author attacks the weakest interface, not how people actually ship with these tools.
Third, non-determinism isn't disqualifying. Plenty of effective engineering tools are stochastic (fuzzers, search/optimization, SAT/SMT with heuristics). Determinism comes from external specs: unit/integration tests, type systems, property-based tests, CI gates.
False dichotomy: "LLMs are popular only because languages/libraries are bad." Languages are improving (e.g. Rust, Typescript), yet LLMs still help because the real bottlenecks are API lookup, cross-repo reading, boilerplate, migrations, test writing, and refactors, the areas where retrieval and synthesis shine. These are complementary forces, not substitutes.
Finally, no constructive alternatives are offered. "Build better compilers/languages" is fine but modern teams already get value by pairing those with AI: spec-first prompts, test-gated edits, typed SDK scaffolds, auto-generated tests, CI-verified refactors, and repo-aware agents.
A much better way to think about AI coding and LLMs is that they aren’t compilers. They’re probabilistic code synthesizers guided by your constraints (types, tests, CI). Treat them like a junior pair-programmer wired into your repo, search, and toolchain. But not like a magical English compiler.
"LLM coding tools are search-based program synthesizers," in my mind this is what compilers are. I think most compilers do far too little search and opt for heuristics instead, often because they don't have an integrated runtime environment, but it's the same idea.
"Plenty of effective engineering tools are stochastic," sure but while a SAT solver might use randomness and that might adjust your time to solve, it doesn't change the correctness of the result. And for something like a fuzzer, that's a test, which are always more of a best effort thing. I haven't seen a fuzzer deployed in prod.
"Determinism comes from external specs and tests," my dream is a language where I can specify what it does instead of how it does it. Like the concept of Halide's schedule but more generic. The computer can spend its time figuring out the how. And I think this is the kind of tools AI will deliver. Maybe it'll be with LLMs, maybe it'll be something else, but the key is that you need a fairly rigorous spec and that spec itself is the programming. The spec can even be constraint based instead of needing to specify all behavior.
I'm not at all against AI, and if you are using it at a level described in this post, like a tool, aware of its strengths and limitations, I think it can be a great addition to a workflow. I'm against the idea that it's a magical English compiler, which is what I see in public discourse.
A compiler takes source and maps it to some output. Regardless of the compiler detail, this is an atomic operation; you end up with source (unmodified) and an artifact.
These “agent workflows” are distinctly different.
The process of mapping prompt to an output is the same; but these agent workflows are destructive; they modify the source.
Free reign over the entire code base; They modify the tests. The spec, the implementation.
It seems like this is a concept people are still struggling with; if your specification is poorly defined, and is dynamically updated during the compilation process, the results are more than just non deterministic.
Over time, the specification becomes non deterministic.
Thats why unsupervised agents go “off the rails”; not because the specification cant be executed, but because over time the spec drifts.
That doesnt happen with compilers.
in your HN comment: “I agree with this comment, but if I wrote more like this my blog post would get less traction.”
Seems like you also not care about the truth.
It's not a "compiler," it's a "probabilistic code synthesizer guided by your constraints"
The latter is technically more specific and correct than the former, but it's 7 words instead of 1. And the word compiler is understood to encompass the latter, even if most compilers aren't that. They are both "a tool in a workflow"
The problem of course is when people throw away the prompt and keep the code, like the code is somehow valuable. This would be like everyone checking in their binaries and throwing away their source code every time, while arguments rage on HN about whether compilers are useful. (Meanwhile, compiler vendors compete on their ability to disassemble and alter binaries in response to partial code snippets.)
The right way to do AI programming is: English defines the program, generated code is exactly as valuable as compiler output is, i.e. it's the actual artifact that does the thing, so in one sense it's the whole point, but iterating on it or studying it in detail is a waste of time, except occasionally when debugging. It's going to take a while, but eventually this will be the only way anybody writes code. (Note: I may be biased, as I've built an AI programming tool.)
If you can explain what needs to be done to a junior programmer in less time than it takes to do it yourself, you can benefit from AI. But, it does require totally rethinking the programming workflow and tooling.
I think that the only useful objects to keep right now are DSPy programs together with well-crafted examples, with examples being the most valuable because they are transferable across models and architectures.
I also noticed several people in the thread comparing coding assistants to junior programmers. I disagree. The only parallel is that they will do what you tell them to. Otherwise, a coding assistant can hold an entire codebase in context, reason across patterns, and generate boilerplate faster than any human. That capability has no human analogue. And unlike a junior, they have no agency, so the comparison breaks down on multiple fronts.
> This isn’t to say “AI” technology won’t lead to some extremely good tools. But I argue this comes from increased amounts of search and optimization and patterns to crib from, not from any magic “the AI is doing the coding”
* I can tell claude code to crank out some basic crud api and it will crank it out in a minute saving me an hour or so.
* I need an implementation of an algorithm that has been coded a million times on github, I ask the AI to do it and it cranks out a correct working implementation.
If I only use the AI in its wheelhouse it works very well, otherwise it sucks.
My tests with full trace level logging enabled can get very verbose. It takes serious time for a human to parse where in the 100 lines of text the relevant part is.
Just telling an AI: "Run the tests and identify the root cause" works well enough, that nowadays it is always my first step.
Think about this. Before there were cars on roads, people were just as much happy. Cars came, cities were redesigned for cars with buildings miles apart, and commuting miles became the new norm. You can no longer say cars are useless because the context around them has changed to make the cars a basic need.
AI does same thing. It changes the context in which we work. Everyone expects you use AI (and cars). It becomes a basic need, though a forced one.
To go further, hardly anything produced by science or technology is a basic need for humans. The context got twisted, making them basic needs. Tech solutions create the problems which they claim to solve. The problem did not exist before the solution came around. That's core driving force of business.
The specific time sucks measured in the study are addressable with improved technology like faster LLMs and improved methodology like running parallel agents—the study was done in March running Claude 3.7 and before Claude Code.
We also should value the perception of having worked 20% less even if you actually spent more time. Time flies when you’re having fun!
But to stop here and say AI coding doesn't work will just not hold up well. We have a sample size of 16 developers for 250 tasks.
Here is my data point: adding AI to your engineering team really is like adding a new member. At first it slows everybody down: explain this, explain that, stupid mistake made that the experienced dev would have avoided. But over the months you learn how to get the most out of them: they speak fluently all programming languages, don't mind writing 20 tests or coming up with good industry ideas to your problems.
Over time I have come to appreciate that the market is rather smart and even hype has its place. You often have to cross a line to know you crossed it, especially with something as fuzzy and quickly changing as technological progress hitting the messy real world. But then again, we need the heretics to stay smart and not follow an emperor without clothes.
The person who showed a speed-up indicated over a week of prior experience with cursor while all others under a week.
But for people who aren’t seasoned coders, these tools are incredibly valuable. I have some coding experience myself, but it’s never been my profession (I’m a visual artist). Now, I can accomplish in an afternoon what would otherwise take me days. Two months ago I left my job to work solo on my video game, and even though my budget is limited, I still make sure to keep Claude and ChatGPT. Also, being able to write something on my phone at 1 a.m. when I can’t sleep, send it to Codex, and then test it first thing in the morning at my computer feels pretty magical. It also takes away the worry of “what if this isn’t the best way to do it?” since refactoring parts of my codebase is now so easy. It helps not just with writing code, but also with removing the fear that might otherwise keep me from sitting down and getting the work done.
That said, I understand that much of the criticism is really aimed at the marketing hype around these tools and the broader “this will replace the engineers at your company” narrative.
He is right, however AI is still darn useful. He hints at why: patterns.
Writing a test suite for a new class when an existing one is in place is a breeze. It even can come up with tests you wouldnt have thought of or would have been too time pressed to check.
It also applies to non-test code too. If you have the structure it can knock a new one out.
You could have some lisp contraption that DRYs all the WETs so there is zero boilerplate. But in reality we are not crafting these perfect cosebases, we make readable, low-magic and boilerplatey code on tbe whole in our jobs.
But I do closely review the code! It turns the usual drudge of writing tests into more of a code review. Last time I did it it had some mistakes I needed to fix for sure.
A lot of the tests have those things. Boilerplate becomes knowing which to use, as well as the it.each(...) etc. ceremonies
Adderall is similar. It makes people feel a lot more productive, but research on its effectiveness[0] seems to show that, at best, we get only a mild improvement in productivity, and marked deterioration of cognitive abilities.
The ADHD was caught early, and treated, but the dyslexia was not. He thought he was a moron, for much of his early life, and his peers and employers did nothing to discourage that self-diagnosis.
Since he learned of his dyslexia, and started treating it, he has been an engineer at Intel, for most of his career (not that I envy him, right now).
Their benefits when used as intended are solidly documented in research literature.
It seems like that with such small groups and effects you could run the same “study” again and again until you get the result that you initially desired.
https://pmc.ncbi.nlm.nih.gov/articles/PMC3489818/table/tbl1/
If legitimate research had found it to be drastically better, that study would definitely have been published in a big way.
Unscientifically, I personally know quite a number of folks that sincerely believed that they couldn’t function without it, but have since learned that they do far better on their own. I haven’t met a single one that actually had their productivity decline (after an adjustment period, of course), after giving up Adderall. In fact, I know several, that have had their careers really take off, after giving it up.
"Antibiotics don't improve your life, but can damage your health" would likely be the outcome on 13 randomly selected healthy individuals. But do the same study on 13 people with a bacterial infection susceptible to antibiotics and your results will be vastly different.
They'll need to learn, the same way I see lots of people learn.
It's been around long enough, though, that all the Adderall-eating people should have established a Gattaca-like "elite," with all us "undermen," scrabbling around at their feet.
Not sure why that never happened...
It's not that they make you superhuman - I don't think I'm any "smarter" on them. It's just that without them, my "productive" bursts would be at really random times (11PM or 2AM), and make it very hard to fit into a "normal" schedule with the rest of society (I would frequently fall asleep in classes or meetings).
So it's more that it allows you to "rearrange" the same (or slightly larger) amount of work but into a more reasonable, traditional schedule. And for certain things, helps more than that. But it's not a miracle drug by any means.
People without ADHD take it, believing that it makes them “super[wo]men.”
That said, I'll leave the conclusions about whether it's valuable for those with ADHD to the mental health professionals.
A lot of it. Other stuff, too, that makes it look like a cup of weak tea, but it’s been 45 years.
I’m pretty familiar with the illusion of productivity.
>I’m pretty familiar with the illusion of productivity
II do not have ADHD and I'm familiar with successfully using Aderrall for actual productivity. YMMV. Turns out not everyone's brain chemistry is the same.
I just make sure there's a place to go, if the wheels fall off.
Cheers.