This article is a bit rambly so I'll just focus on some things from the beginning:
>If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in.
This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates.
To use one product as an example: When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP and a pretty good OS in Windows 7 respectively. No longer is that an option, your workflow will simply be interrupted by automatic updates.
>Vim and Emacs, in their infinite customizability, can be molded to fit your exact hand and workflow
Vim is one major exception to the automatic update problem. I trust vim not just because it can do a ton of shit (although that is certainly nice), but because unlike most other software, its UI doesn't change unless I tell it to change. Aside from switching from vim to neovim (my decision, not a forced update), my muscle memory from a couple decades ago still works today.
> Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP
Prior to XP, MS had two lines of Windows: the Windows 9x kernels and the Windows NT kernels. Windows XP was meant to be the merger of the two lines, adapting Windows NT to have compatibility with Windows 95 and Windows 98 features. Unfortunately, Windows XP development went overlong, so MS wedged in Windows ME to give a stop-gap release until XP could actually be released.
There's this great blog post by Joel Spolsky from 2000 [1], where he essentially argues that controlling your environment makes you happy. He writes about his summer job in a bakery and how the dough mixers would be so unpredictable and how frustrating that was. I think AI agents are quite similar to a lot of folks, they change significantly with each major model update and even every day as the vendor tweaks the system prompts and settings, so you never feel "in control", it's more like pushing buttons on some blackbox and hoping the right stuff happens inside. Most people are unhappy about that as it takes away the mastery and craft aspect of software development and makes them managers of unpredictable AI tools. I certainly get this feeling even though I like AI in general, but having days where everything goes so well working with the agent and then days where nothing really seems to work and not knowing why is quite frustrating.
> and even every day as the vendor tweaks the system prompts
I just patched Claude Code's system prompts, pinned the version and stopped upgrading without first dissecting and auditing the executable. Even discovered Anthropic can remotely inject strings into the system prompt via some "growth book" or something. Neutralized that too.
Things got a lot better after I started doing this. It straight up fixed Opus 4.6, and Opus 4.8 got more consistent in my subjective experience.
Sadly there's nothing I can do about Anthropic's server side "system reminders" whenever some prompt trips their classifiers or whatever.
I'm in the process of switching to OpenAI and Codex. The open source harness is a breath of fresh air. We'll see how that goes.
I feel like these abstractions like "CI might not work well in the era of agentic tooling" are fine for thought-leadership posts but there's so much hands-on work to be done. The last word on AI computer use shouldn't be bash utils that were already feature-complete before MJ recorded Thriller.
There is some movement in this direction--there is a new 'gh' subcommand called repo read-file for example, that lets agents view a file without cloning a repo. And I made something called venetianblinds that shows equidistant samples of a file. In combo they work pretty well:
--- sample 2/20 char 283427 line 5855 col 53 range 283367:283487
le].
**
** ^Closing a BLOB shall cause the current transaction to commit
** if there are no other BLOBs, no pending prep
^
I've found the process of building good reliable CI that thoroughly covers everything has been greatly improved by LLMs. There's so much tedious plumbing and grunt work involved in building CI and automated testing infrastructure for bespoke products that they can handle just fine while you concentrate on the important bits - I would say it's an area where agentic workflows are even more suited than regular product code.
Hand-crafted, domain-specific tools massively outperform general purpose ones.
Shell execution and raw DOM access are great for a backstop, but you can go so much further with just a little bit of translation and delegation around the environment.
I think browser automation is probably the most apt scenario. Often a human who understands how a page is meant to be perceived can transform a megabyte of raw web content down to a few hundred bytes of plaintext without any reduction in fidelity. This can be achieved using deterministic code that is guaranteed to provide a perfect transform every time.
The performance difference between raw DOM access and curated plaintext is like a step function. With raw access you get maybe 10-15 steps into a complex workflow before the wheels pop off. With curated access I've seen it go 100+ screens without issues.
Simply managing the token bloat is probably the most important objective here. If that's all you focus on it will probably go really well.
Yeah as far as what I'm talking about bash CLI vs MCP doesn't matter (there could be a file_sample MCP tool)---I'm saying that by default Windows, Linux etc don't have this venetianblinds affordance of seeing equally spaced samples. It's a trivial algo but it's very handy these days cause LLMs can't really just be like 'okay I'm gonna open this file at random and scroll around'--the file itself is an unknown blob (JSON data, Python, Typescript, a log file etc) without coordinates. So they fall back to thinking they've gotten a good sense of the file from head/grep or they write ad-hoc Python to manipulate the file.
Another venetianblinds survey, of the Paul Graham 'What I Worked On' article that's used in many LlamaIndex examples:
npx github:firasd/venetianblinds pgworkedon.txt
--- sample 1/20 char 0 line 1 col 1 range 0:60
Before college the two main things I worked on, outside of s
--- sample 2/20 char 3946 line 19 col 237 range 3886:4006
d an intelligent computer called Mike, and a PBS documentary that showed Terry Winograd using SHRDLU. I haven't tried re
Problem is that bash is too sharp to handle to smart and gullible clankers without a sandbox - That I think everyone should be using anyways, for everything, even things not related to clankers - Android and Qubes are right. The app/vm, and whatever it tries, should not be considered trusted by default.
Qubes is directionally correct, Android is extremely not. Safety must not be obtained by preventing users from controlling their own computing devices, or else we face a dire future.
Im typing this in GVim thanks to Tridactyl using my new mechanical keyboard running a ZMK firmware I just built via Github actions (or directly via ZMK Studio).
This is ridiculously complex to just type a few paragraphs. Nobody in their right mind would invest this amount of yak shaving... and yet I do so because I bet, rather confidently, that in few years, heck few decades, all those tools will be different (or maybe not, I still use Vim on my server, desktop but even mobile phone) but the lessons will remain practical.
IMHO the trust comes from trust yes but also more directly plain ownership.
I'm not sure the difference changes the conclusion but I think projects demanded certain workflows and resultant processes, not the other way around. That's why Jetbrains has so many workstream specific IDEs that sold very well. The processes didn't go away but a lot of us changed our IDE surface. Those processes still need to exist, largely, but the way in which we invoke them is moving and changing. To some degree, the processes are also changing because other factors are changing outside of the tooling.
For example, I use Codex and Claude Code by default, but when I need to look at the API surface, read tests, etc I have those tools setup to open Zed. Zed is also rapidly evolving in the other direction, where it's closer to the tools that are opening it. It won't be long, I think, until I can continue my prompt from inside Zed.
Stack Overflow conveniently defining the problem in a way that makes SO the answer. The irony is that the kind of code review that LLMs make possible would never have been doable on SO lest you be accused of trying to 'outsource the work'.
Now agentic coding produces the full 100 line change, and SO says the real crisis is that nobody has reviewed it properly. SO was fully responsible for creating the culture where no one wanted to use it.
An example of this in action is the utter inability to get deepseek v4 flash (even the new version) to stay concise. I have jumped through all sorts of hoops with deterministic checks, pre-message injection hooks, memory framework, etc and when it fails still and I ask why it essentially says "I forgot."
This makes it unreliable and preferences are things I need to assume are treated as exactly that, preferences, not hard settings.
It is an area where it is more like working with an unreliable human than I would prefer.
I have to admit, I asked ChatGPT to do a TLDR summary because I found the writing meandered quite a bit. I think the overall point is sound:
> "Developers become attached to tools like Vim, Emacs, or an IDE because years of experience make those tools predictable extensions of their thinking. The attachment is less about features and more about accumulated trust, muscle memory, and a workflow built around known boundaries.
> AI coding agents disrupt that trust because they are fast but probabilistic, opaque, constantly changing, and capable of producing more code than humans can realistically review. This shifts the bottleneck from writing code to specifying, reviewing, validating, and operating it safely."
(Note the > is paraphrasing)
Trust is a big problem I'm having with these tools so far. What I've been running into a lot is, I'll get the equivalent 40 hours of work done in 8 hours, and I'm like, wow, that really was quick. Then I'll start using the application I'm making more directly (a tool for writing), and I'll start to see that it's broken all over the place in very surprising ways (ie, updating this menu item broke something on the other side of the app, etc.). So then I spend another 40 hours of real wall clock time kind of fixing everything that was broken, and at the end of those two weeks I'm like, did I actually go much faster or was that all kind of a wash? Because if I'm not going faster in overall terms, then the loss of deep understanding of the code base might not be worth it if my pace is the same.
I'm sure someone is going to be like "BRUH AUTOMATED TESTS" or "BRUH MODEL CHOICE". I have a LOT of automated tests, and I don't like fussing with models so I pretty much use Opus on high reasoning for most things (or the equivalent from other providers). Code review also doesn't help that much, for much of the same reason it doesn't tend to help find bugs in human written code either.. you're reading the happy path usually.
Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.
If you are spending 40 hours fixing everything that was broken, the question I have is does your AI tools have the necessary context to be successful and not result in a lot of broken items?
Also, is there ways for AI to help prevent the loss of deep understanding of your code base without you having to know every line of code deeply?
I was a bit hazy on numbers because I don't scientifically record them, but I guess what I'll say is the fixing and verifying takes a lot longer than writing the initial code. This was true before LLMs, but when writing code by hand I had the context of the code in my head, so potential issues, blast radius, etc. was a lot more obvious. By definition most of the things that break are things that are not trivially testable. Unfortunately, it's not as easy as saying "Claude, the thing broke, plz fix"; I've had to spend a lot of time recently helping it with context from debuggers, or just debugging myself manually, adding log statements, etc.
Am I giving the agent enough context? Well, I'm giving it as much as I can. Each submodule has an AGENTS.md, I have the agents add gotchas and instructions for some feature work when I discover where an agent went wrong, the codebase has a lot of comments along the lines of "if you edit this section, you need to also edit XYZ", and I lean on the type system as much as I can to make wrong-code not compile. It has access to playwright for driving the UI if it wants to. (Weirdly, I've found that Claude is really inconsistent about using these tools -- even though the instructions make it clear that it's allowed and encouraged. I think if your workflow differs from the models training and thusly you have to tell it so in AGENTS.md/CLAUDE.md, then it's very inconsistent about following those instructions. For instance, I don't want Claude to commit and I don't want it to sign commit messages, and it still does that all the time even though it's my like #1 directive of "don't mess with my git history")
There are some things though that are very hard for it to test. I'm exporting essentially a programming language to three game engine runtimes. They all have automated tests, but, I think people that have worked in video games know that games are very hard to automate testing on. This isn't really the fault of the agent I would say, just the nature of the problem, but it is worth noting.
I guess this is a long winded way of saying, even with LLMs tech debt is a thing you have to manage, and I think managing tech debt becomes even more important when you're dealing with LLMs, not less important.
"40 hours" in his context here is actually a work day, so 7-8hrs.
He says "40 hours" because he feels like he's managed to do 40 hours worth of work in this time, but then has to spend another "40 hours" (actually: 1 day) just going around kicking tyres.
Obviously the implication is that it's a net gain of some kind, but he's unsure if he caught everything.
(sorry to reiterate the GP, but I feel like you missed the important nuance that it's not a real 40 hours of time).
I was surprised to see you say you have automated tests. To me this makes most of the difference, but you have you actually have a good test suite, like one that actually proves the code does what you want it to do. Unit tests, property tests, e2e tests. The other part that makes all difference, is you have to be all up in the model's business about architecture. Pick something that wants to testable and isolation friendly, data models that are correct by construction (ie invalid states are not expressible), etc. It absolutely will try to cut corners give you bullshit slop at every turn, you have to keep the structure sane and build the right tests and harness around it.
And I can hear your objection now: correct, it's probably not worth all that for a throwaway, but the effort per output goes down as the infra builds up and you end up with a program that can reliably expand.
Wait; So you say you outsource development to a LLM fully knowing that it will not write sound/deterministic code and your quality requirement are your test cases, right?
I further suppose you are not writing the test cases in its whole by hand. But you try to specify them before you hand out the development task to the LLM, right?
It sounds like you just introduces a new team member which is not trustworthy yet.
Normally you would review each change of him and explain how to improve hisself and the code.
But that's not possible to a fixed-state LLM.
That sounds exhausting.
If your Markdown Files should aim at improving the LLM contributions, you are again stuck with the fact that it did not follow in the first place.
So I conclude: You pay for an Intern who is not trustworthy and pay additional input token on Markdown Files to still no be certain about future contributions.
I just don't grasp how we as engineers are accepting this and integrate it into our craft.
And: Everybody using External LLM Services, possibly providing the entire project as context, is allowed to let the source code of your company be leaked to some third party. I hope that party is trustworthy and does not have a track record of copyright infridgement. Because this would be fairly naive and reason to be fired. So we as Engineers knowing the implications should therefore point to these issues at the correct management level.
I think testing is really important (even without LLMs). Currently I have 2247 unit tests across 132 files in a ~150K LOC codebase (test code included in that count). It takes about 50s to run. There could be more, but it's not nothing. There is playwright for it to test drive the UI, although if I'm being perfectly honest even before LLMs I thought that kind of test tends to be brittle and annoying to write (I guess I don't have to write them anymore, but they are still brittle). I'm honestly trying to give it as much structure as I possibly can -- I'm not trying to setup the agent to fail so I can be like "gotcha!"
I'll also just point out my philosophy for using LLMs for this project, which is that I'm not trying to go as fast as I can. (I want to go at a good pace, but this isn't an experiment to just finish something over a weekend). The 150k LOC have come about since February, with some mix of me writing code and LLMs, so on average I'm probably bringing in about 800 LOC per day, which I imagine a lot of vibers would find to be glacial. To me that's the sustainable rate of what I can do when you factor in that I need to test drive every feature, make sure it doesn't conflict with another feature, check for bugs, check that the code looks reasonable, and debugging. (I also think that rate limit is specific to this project: I could see easier to test things going much faster, and harder to test things going slower)
Isn't being brittle kinda the point of playwright tests? Because each test uses the whole app those tests can catch errors that happen at many places in the code. But that means lots of things can cause a test failure.
> Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.
My own stance is that there's never any reason to go fast on anything. Communication has always been the bottleneck. Whether it's about gathering requirements or understanding the purpose of a badly written code, any speed improvements I get has always been a small percentage of the overall progress.
What has helped more is my understanding of the platform and some theoretical knowledge. Because one I get the information, I can quickly derive a solution in my mind. And that solution has always been easy and fast to implement, at least the happy path. 90% of the time taken in coding is always about handling all the edge cases, aka fixing bugs. And writing tests so that you're not easily introducing more bugs.
I operate on zero trust because I find that people won't trust me regardless of what their stated reasons are. They just feel uncomfortable. On top of that, people will hallucinate things in order to not trust me.
I update my toolset all the time. It always results in discomfort and backlash but people don't understand that the goal isn't their perception or trust. It's about skill, ability, and execution. This idea probably won't get me promoted but it will get me paid. I am not attached to tools because I learned the hard way that they will always find a way to take them from me.
Zero trust is a better alternative for people like me. In terms of cybersecurity, being attached to a tool is crutch because fatal flaws in every design are frequently found. As it relates to agentic AI, I never select the "Yes, trust the AI and let Claude execute arbitrary commands in a non-sandboxed environment" option. However, I frequently utilize agents, but I'm not going to have the "Jesus, take the wheel" moment with them right now. That being said, AI is a very helpful tool that helps me create boilerplate code, brainstorm ideas, and review my work. I also anticipate when AI can, in fact, take the wheel and I'm looking forward to it.
Parallel to this, I also know that developers often disagree, and I'm not casting judgement on anyone for being attached. If it's Turing-complete, then I have the background to complete the task. In these scenarios, I just adopt whatever tools work best in team building because, in my own words, I'm not too attached to the way I do things.
I agree with this article, but it's so much more than just trust in a workflow.
It's an API you can trust, in an ocean of change.
That's what you're choosing; an api, abi... whatever you call it.
You're committing to an extensible boundary.
And both the boundary, and the extensibility (not to mention the openness) are why they win.
And shelling out to a cli? That's a pretty damn compelling and composable boundary, IMO.
This article is a bit rambly so I'll just focus on some things from the beginning:
>If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in.
This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates.
To use one product as an example: When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP and a pretty good OS in Windows 7 respectively. No longer is that an option, your workflow will simply be interrupted by automatic updates.
>Vim and Emacs, in their infinite customizability, can be molded to fit your exact hand and workflow
Vim is one major exception to the automatic update problem. I trust vim not just because it can do a ton of shit (although that is certainly nice), but because unlike most other software, its UI doesn't change unless I tell it to change. Aside from switching from vim to neovim (my decision, not a forced update), my muscle memory from a couple decades ago still works today.
> Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP
Prior to XP, MS had two lines of Windows: the Windows 9x kernels and the Windows NT kernels. Windows XP was meant to be the merger of the two lines, adapting Windows NT to have compatibility with Windows 95 and Windows 98 features. Unfortunately, Windows XP development went overlong, so MS wedged in Windows ME to give a stop-gap release until XP could actually be released.
There's this great blog post by Joel Spolsky from 2000 [1], where he essentially argues that controlling your environment makes you happy. He writes about his summer job in a bakery and how the dough mixers would be so unpredictable and how frustrating that was. I think AI agents are quite similar to a lot of folks, they change significantly with each major model update and even every day as the vendor tweaks the system prompts and settings, so you never feel "in control", it's more like pushing buttons on some blackbox and hoping the right stuff happens inside. Most people are unhappy about that as it takes away the mastery and craft aspect of software development and makes them managers of unpredictable AI tools. I certainly get this feeling even though I like AI in general, but having days where everything goes so well working with the agent and then days where nothing really seems to work and not knowing why is quite frustrating.
1: https://www.joelonsoftware.com/2000/04/10/controlling-your-e...
> and even every day as the vendor tweaks the system prompts
I just patched Claude Code's system prompts, pinned the version and stopped upgrading without first dissecting and auditing the executable. Even discovered Anthropic can remotely inject strings into the system prompt via some "growth book" or something. Neutralized that too.
Things got a lot better after I started doing this. It straight up fixed Opus 4.6, and Opus 4.8 got more consistent in my subjective experience.
Sadly there's nothing I can do about Anthropic's server side "system reminders" whenever some prompt trips their classifiers or whatever.
I'm in the process of switching to OpenAI and Codex. The open source harness is a breath of fresh air. We'll see how that goes.
I feel like these abstractions like "CI might not work well in the era of agentic tooling" are fine for thought-leadership posts but there's so much hands-on work to be done. The last word on AI computer use shouldn't be bash utils that were already feature-complete before MJ recorded Thriller.
There is some movement in this direction--there is a new 'gh' subcommand called repo read-file for example, that lets agents view a file without cloning a repo. And I made something called venetianblinds that shows equidistant samples of a file. In combo they work pretty well:
gh repo read-file sqlite3.c --repo clibs/sqlite --output sqlite3.c && npx github:firasd/venetianblinds sqlite3.c
I've found the process of building good reliable CI that thoroughly covers everything has been greatly improved by LLMs. There's so much tedious plumbing and grunt work involved in building CI and automated testing infrastructure for bespoke products that they can handle just fine while you concentrate on the important bits - I would say it's an area where agentic workflows are even more suited than regular product code.
Hand-crafted, domain-specific tools massively outperform general purpose ones.
Shell execution and raw DOM access are great for a backstop, but you can go so much further with just a little bit of translation and delegation around the environment.
I think browser automation is probably the most apt scenario. Often a human who understands how a page is meant to be perceived can transform a megabyte of raw web content down to a few hundred bytes of plaintext without any reduction in fidelity. This can be achieved using deterministic code that is guaranteed to provide a perfect transform every time.
The performance difference between raw DOM access and curated plaintext is like a step function. With raw access you get maybe 10-15 steps into a complex workflow before the wheels pop off. With curated access I've seen it go 100+ screens without issues.
Simply managing the token bloat is probably the most important objective here. If that's all you focus on it will probably go really well.
MCP is the answer to not using bash, right?
Bash is a great control surface anyway for LLMs as it is wordy and powerful.
Yeah as far as what I'm talking about bash CLI vs MCP doesn't matter (there could be a file_sample MCP tool)---I'm saying that by default Windows, Linux etc don't have this venetianblinds affordance of seeing equally spaced samples. It's a trivial algo but it's very handy these days cause LLMs can't really just be like 'okay I'm gonna open this file at random and scroll around'--the file itself is an unknown blob (JSON data, Python, Typescript, a log file etc) without coordinates. So they fall back to thinking they've gotten a good sense of the file from head/grep or they write ad-hoc Python to manipulate the file.
Another venetianblinds survey, of the Paul Graham 'What I Worked On' article that's used in many LlamaIndex examples:
npx github:firasd/venetianblinds pgworkedon.txt
Also, this is a trivial example but I would rather an LLm call a recursive "grep" than using 1000 read_file MCP calls.
Having a scripting language as a tool is powerfull, and can help remove unnecessary stuff from the LLM's context.
Problem is that bash is too sharp to handle to smart and gullible clankers without a sandbox - That I think everyone should be using anyways, for everything, even things not related to clankers - Android and Qubes are right. The app/vm, and whatever it tries, should not be considered trusted by default.
Qubes is directionally correct, Android is extremely not. Safety must not be obtained by preventing users from controlling their own computing devices, or else we face a dire future.
This is a lot of words to say absolutely nothing. Seems apropos for Stack Overflow though.
Im typing this in GVim thanks to Tridactyl using my new mechanical keyboard running a ZMK firmware I just built via Github actions (or directly via ZMK Studio).
This is ridiculously complex to just type a few paragraphs. Nobody in their right mind would invest this amount of yak shaving... and yet I do so because I bet, rather confidently, that in few years, heck few decades, all those tools will be different (or maybe not, I still use Vim on my server, desktop but even mobile phone) but the lessons will remain practical.
IMHO the trust comes from trust yes but also more directly plain ownership.
I'm not sure the difference changes the conclusion but I think projects demanded certain workflows and resultant processes, not the other way around. That's why Jetbrains has so many workstream specific IDEs that sold very well. The processes didn't go away but a lot of us changed our IDE surface. Those processes still need to exist, largely, but the way in which we invoke them is moving and changing. To some degree, the processes are also changing because other factors are changing outside of the tooling.
For example, I use Codex and Claude Code by default, but when I need to look at the API surface, read tests, etc I have those tools setup to open Zed. Zed is also rapidly evolving in the other direction, where it's closer to the tools that are opening it. It won't be long, I think, until I can continue my prompt from inside Zed.
Stack Overflow conveniently defining the problem in a way that makes SO the answer. The irony is that the kind of code review that LLMs make possible would never have been doable on SO lest you be accused of trying to 'outsource the work'.
Now agentic coding produces the full 100 line change, and SO says the real crisis is that nobody has reviewed it properly. SO was fully responsible for creating the culture where no one wanted to use it.
An example of this in action is the utter inability to get deepseek v4 flash (even the new version) to stay concise. I have jumped through all sorts of hoops with deterministic checks, pre-message injection hooks, memory framework, etc and when it fails still and I ask why it essentially says "I forgot."
This makes it unreliable and preferences are things I need to assume are treated as exactly that, preferences, not hard settings.
It is an area where it is more like working with an unreliable human than I would prefer.
Lots of people saying the same about Deepseek v4 Flash. Seems like it's an artifact of that model.
I have to admit, I asked ChatGPT to do a TLDR summary because I found the writing meandered quite a bit. I think the overall point is sound:
> "Developers become attached to tools like Vim, Emacs, or an IDE because years of experience make those tools predictable extensions of their thinking. The attachment is less about features and more about accumulated trust, muscle memory, and a workflow built around known boundaries.
> AI coding agents disrupt that trust because they are fast but probabilistic, opaque, constantly changing, and capable of producing more code than humans can realistically review. This shifts the bottleneck from writing code to specifying, reviewing, validating, and operating it safely."
(Note the > is paraphrasing)
Trust is a big problem I'm having with these tools so far. What I've been running into a lot is, I'll get the equivalent 40 hours of work done in 8 hours, and I'm like, wow, that really was quick. Then I'll start using the application I'm making more directly (a tool for writing), and I'll start to see that it's broken all over the place in very surprising ways (ie, updating this menu item broke something on the other side of the app, etc.). So then I spend another 40 hours of real wall clock time kind of fixing everything that was broken, and at the end of those two weeks I'm like, did I actually go much faster or was that all kind of a wash? Because if I'm not going faster in overall terms, then the loss of deep understanding of the code base might not be worth it if my pace is the same.
I'm sure someone is going to be like "BRUH AUTOMATED TESTS" or "BRUH MODEL CHOICE". I have a LOT of automated tests, and I don't like fussing with models so I pretty much use Opus on high reasoning for most things (or the equivalent from other providers). Code review also doesn't help that much, for much of the same reason it doesn't tend to help find bugs in human written code either.. you're reading the happy path usually.
Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.
If you are spending 40 hours fixing everything that was broken, the question I have is does your AI tools have the necessary context to be successful and not result in a lot of broken items?
Also, is there ways for AI to help prevent the loss of deep understanding of your code base without you having to know every line of code deeply?
I was a bit hazy on numbers because I don't scientifically record them, but I guess what I'll say is the fixing and verifying takes a lot longer than writing the initial code. This was true before LLMs, but when writing code by hand I had the context of the code in my head, so potential issues, blast radius, etc. was a lot more obvious. By definition most of the things that break are things that are not trivially testable. Unfortunately, it's not as easy as saying "Claude, the thing broke, plz fix"; I've had to spend a lot of time recently helping it with context from debuggers, or just debugging myself manually, adding log statements, etc.
Am I giving the agent enough context? Well, I'm giving it as much as I can. Each submodule has an AGENTS.md, I have the agents add gotchas and instructions for some feature work when I discover where an agent went wrong, the codebase has a lot of comments along the lines of "if you edit this section, you need to also edit XYZ", and I lean on the type system as much as I can to make wrong-code not compile. It has access to playwright for driving the UI if it wants to. (Weirdly, I've found that Claude is really inconsistent about using these tools -- even though the instructions make it clear that it's allowed and encouraged. I think if your workflow differs from the models training and thusly you have to tell it so in AGENTS.md/CLAUDE.md, then it's very inconsistent about following those instructions. For instance, I don't want Claude to commit and I don't want it to sign commit messages, and it still does that all the time even though it's my like #1 directive of "don't mess with my git history")
There are some things though that are very hard for it to test. I'm exporting essentially a programming language to three game engine runtimes. They all have automated tests, but, I think people that have worked in video games know that games are very hard to automate testing on. This isn't really the fault of the agent I would say, just the nature of the problem, but it is worth noting.
I guess this is a long winded way of saying, even with LLMs tech debt is a thing you have to manage, and I think managing tech debt becomes even more important when you're dealing with LLMs, not less important.
"40 hours" in his context here is actually a work day, so 7-8hrs.
He says "40 hours" because he feels like he's managed to do 40 hours worth of work in this time, but then has to spend another "40 hours" (actually: 1 day) just going around kicking tyres.
Obviously the implication is that it's a net gain of some kind, but he's unsure if he caught everything.
(sorry to reiterate the GP, but I feel like you missed the important nuance that it's not a real 40 hours of time).
No the second 40 hours is a real 40 hours (two weeks), and the implication is there is no real time saving.
Wow, just wow. This is the first time I've encountered this particularly AI apologism. To recap:
Alice: "in the end, AI doesn't make me any faster because it still takes 80 hours to do 80 hours of work once I fix it"
Bob (AI booster): "actually you might've been holding it wrong, did you try XYZ?"
Carol (super AI booster): "Bob, actually Alice means it took 16 hours to do 80 hours of work. So it did work for her."
Alice: "no I fucking didn't"
Sorry, my original phrasing was confusing which you should not be downvoted for. I've edited my original comment to clarify what I meant (hopefully).
I have it give me a punchlist and a tldr in a table format for every turn. It helps cut through the incessant babbling.
I was surprised to see you say you have automated tests. To me this makes most of the difference, but you have you actually have a good test suite, like one that actually proves the code does what you want it to do. Unit tests, property tests, e2e tests. The other part that makes all difference, is you have to be all up in the model's business about architecture. Pick something that wants to testable and isolation friendly, data models that are correct by construction (ie invalid states are not expressible), etc. It absolutely will try to cut corners give you bullshit slop at every turn, you have to keep the structure sane and build the right tests and harness around it.
And I can hear your objection now: correct, it's probably not worth all that for a throwaway, but the effort per output goes down as the infra builds up and you end up with a program that can reliably expand.
Wait; So you say you outsource development to a LLM fully knowing that it will not write sound/deterministic code and your quality requirement are your test cases, right?
I further suppose you are not writing the test cases in its whole by hand. But you try to specify them before you hand out the development task to the LLM, right?
It sounds like you just introduces a new team member which is not trustworthy yet. Normally you would review each change of him and explain how to improve hisself and the code. But that's not possible to a fixed-state LLM. That sounds exhausting.
If your Markdown Files should aim at improving the LLM contributions, you are again stuck with the fact that it did not follow in the first place.
So I conclude: You pay for an Intern who is not trustworthy and pay additional input token on Markdown Files to still no be certain about future contributions.
I just don't grasp how we as engineers are accepting this and integrate it into our craft. And: Everybody using External LLM Services, possibly providing the entire project as context, is allowed to let the source code of your company be leaked to some third party. I hope that party is trustworthy and does not have a track record of copyright infridgement. Because this would be fairly naive and reason to be fired. So we as Engineers knowing the implications should therefore point to these issues at the correct management level.
At least that's what I am doing shrugs
I think testing is really important (even without LLMs). Currently I have 2247 unit tests across 132 files in a ~150K LOC codebase (test code included in that count). It takes about 50s to run. There could be more, but it's not nothing. There is playwright for it to test drive the UI, although if I'm being perfectly honest even before LLMs I thought that kind of test tends to be brittle and annoying to write (I guess I don't have to write them anymore, but they are still brittle). I'm honestly trying to give it as much structure as I possibly can -- I'm not trying to setup the agent to fail so I can be like "gotcha!"
I'll also just point out my philosophy for using LLMs for this project, which is that I'm not trying to go as fast as I can. (I want to go at a good pace, but this isn't an experiment to just finish something over a weekend). The 150k LOC have come about since February, with some mix of me writing code and LLMs, so on average I'm probably bringing in about 800 LOC per day, which I imagine a lot of vibers would find to be glacial. To me that's the sustainable rate of what I can do when you factor in that I need to test drive every feature, make sure it doesn't conflict with another feature, check for bugs, check that the code looks reasonable, and debugging. (I also think that rate limit is specific to this project: I could see easier to test things going much faster, and harder to test things going slower)
Isn't being brittle kinda the point of playwright tests? Because each test uses the whole app those tests can catch errors that happen at many places in the code. But that means lots of things can cause a test failure.
> Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.
My own stance is that there's never any reason to go fast on anything. Communication has always been the bottleneck. Whether it's about gathering requirements or understanding the purpose of a badly written code, any speed improvements I get has always been a small percentage of the overall progress.
What has helped more is my understanding of the platform and some theoretical knowledge. Because one I get the information, I can quickly derive a solution in my mind. And that solution has always been easy and fast to implement, at least the happy path. 90% of the time taken in coding is always about handling all the edge cases, aka fixing bugs. And writing tests so that you're not easily introducing more bugs.
I operate on zero trust because I find that people won't trust me regardless of what their stated reasons are. They just feel uncomfortable. On top of that, people will hallucinate things in order to not trust me.
I update my toolset all the time. It always results in discomfort and backlash but people don't understand that the goal isn't their perception or trust. It's about skill, ability, and execution. This idea probably won't get me promoted but it will get me paid. I am not attached to tools because I learned the hard way that they will always find a way to take them from me.
Zero trust is a better alternative for people like me. In terms of cybersecurity, being attached to a tool is crutch because fatal flaws in every design are frequently found. As it relates to agentic AI, I never select the "Yes, trust the AI and let Claude execute arbitrary commands in a non-sandboxed environment" option. However, I frequently utilize agents, but I'm not going to have the "Jesus, take the wheel" moment with them right now. That being said, AI is a very helpful tool that helps me create boilerplate code, brainstorm ideas, and review my work. I also anticipate when AI can, in fact, take the wheel and I'm looking forward to it.
Parallel to this, I also know that developers often disagree, and I'm not casting judgement on anyone for being attached. If it's Turing-complete, then I have the background to complete the task. In these scenarios, I just adopt whatever tools work best in team building because, in my own words, I'm not too attached to the way I do things.
What constitutes taking the wheel? Skip permissions in a proper sandbox is fine IMO. There is a small amount of risk I admit though.
I agree with this article, but it's so much more than just trust in a workflow. It's an API you can trust, in an ocean of change. That's what you're choosing; an api, abi... whatever you call it. You're committing to an extensible boundary. And both the boundary, and the extensibility (not to mention the openness) are why they win.
And shelling out to a cli? That's a pretty damn compelling and composable boundary, IMO.