- Work on small projects (< 500k lines of code).
- Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.
- Have clearly defined API boundaries. Examples: If the back end is solid you can just vibe code the first version of a front end according to some mockup. Define a data pipeline with steps and clear contracts of what data gets passed around and what each step does. If the LLM messes up one step, rip it out and rewrite it.
- Have clearly set up workflows for tasks. Start with a "ask me everything" phase, then comes a plan phase, a review phase, an implementation phase, another review phase and then the integration phase. Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through.
- Set up excellent testing. Build your whole architecture around being easy to test.
- Have skills for common problems. For one of my projects I had to set up a skill on how to query the ORM, because Claude was consistently doing database operations in a for loop, where it could use batch operations.
The code in the end is better than a lot of the code I've seen humans write.
I don't think this works for everybody and every project. If you have a culture that values code quality and readability, if you work on large existing projects, if you have to nail the architecture of some non-trivial piece of software etc. you are going to have a bad time.
On the other hand you can probably build the MVP of your AI-supported CRUD app 10-20x faster.
I think a lot of the discussions around development tools and techniques just stem from two facts:
1. Developers work on widely different projects with different management and constraints.
2. Tools, libraries, frameworks and code style have to match your mental model, otherwise you going to dislike them.
> Work on small projects (< 500k lines of code).
> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality.
You then expand on methods and processes that work for you, but I think the crucial question that you do not answer is: How long lived are any of these codebases?
That's always false. It's like people want their meals delivered fast. They say they don't care about taste or how it is done. Watch when they get sick or don't like it and the drama that happens.
People don't care until they do. They don't know what to care (in this case code quality) or say that because you're not explaining it. People also "gamble" and you take the blame. Long term impacts? Nah doesn't matter. Weeks later and things break -- what did you do?
I wouldn't dare doing this "carelessly" for anything where people other than me actually depend on it, but you can move very fast while doing it and the risks with bad code is quite hedged. Different modules can mature at different rates when it becomes necessary.
Maybe not related to all of what you were saying, but I think this enables scaling without ending up with progress grinding down to a halt due to shitty code.
My comment is more for the people in charge of or working on software teams on complicated products for customers - so many leaders quite a few engineers have utterly drank the koolaid and pushed maximizing AI use with zero regard for quality or even medium term effects. Many of them are getting promoted by other clueless management for it - when someone is handed a huge check for being optimistic, they tend not to second guess themselves.
Kinda reminds me of the "beginner's luck" problem for gamblers.
If the answer is yes then atleast you're consistent if no then the question is why can't you scale this until breaks? Then never move beyond that limit?
My argument is there's a "break even" point when the power of the AI is larger than the problem you give it to the point it doesn' slop. You then build at that chunk rate and only try to increase it with next gen model. I usually keep a few "screw it" ideas in my back pocket when a new model arrives to see what happens.
"Go rewrite this entire pipeline in rust" "Go train me a custom x model for y"
Fable is the first model that did not just crash and burn on one of these tasks. Astra still can't do the rust migration (goodbye tokens). But I assume eventually it will. Then I'll have to make up a new ridiculous level.
The model training one was literally an identical pipeline I made before AI and it was like a 6mo process. Fable did it better than me in 1 week (with me helping of course). My theory though is that its datascience is massively higher skill than other systems.
You need to find the chunkrate for your problem and style that works.
When I read posts about AI generating garbage nowadays it’s either because of a small prompt/big ask combination or a lack of an underlying framework.
We're doing other things.
I've got projects that I really care about. Every line of code is written deliberately. It's great.
However, I can't afford to pay so much attention to everything that I do. There are only 24 hours in a day, and my mind has its limits as well. I've found that I can't reliably care deeply about more than two projects at once, and one is the ideal.
The point of AI, at least for me, is to do the other things that I've always wanted to do but never cared enough to. I just put the AI on the task and it gets done at some point, and I don't care if the code is "slop" because it wouldn't even exist to begin with were it not for AI.
While the AI is working on the things I've always wanted but never quite cared enough to do, I'm personally working on the projects I actually care about, or enjoying life in general when I get burned out. For example, a couple weeks ago I was playing video games while the AI was reverse engineering my laptop's BIOS.
I'm not convinced this style of "agentic engineering" saves much time. I guess if I was oblivious to what good code looks like, and didn't care about maintainability It wouldn't bother me so much, but it legitimately has effects my "mental health".
Yes you can have your agents do refinement and refactoring. If you don’t know what they’re doing when they are doing that, they can and do introduce massive churn. The “build it fast and fix it later” crowd seemingly has never had to actually go try to fix it later, or dealt with production incidents when people have no idea how their code works. These folks are frequently promoted fast for their “productivity” and massive promises by clueless management and move on to let others have to clean up their stuff.
Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).
Talk with an LLM, ask them to rate both code and estimate dev experience based on that code, and you will see what they value: Code that passes all the tests is a 10/10, while a codebase designed with opaque data types, Parse-Don't-Validate for all data, isolated interfaces, a built-for-replacement-not-for-extension philosphy will get a 6/10 because an out of bounds error was found.
IOW, they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way - we very highly value code that is easy to maintain, even if they do have a few errors picked up by the linter.
But that requires actually reading the output, which I am pretty certain only a rounding error of programmers are doing at this point.
Blame the benchmarks game. They're optimizing for that and that's what those things are measuring.
Reviewing and reading everything makes this feeling, yeah.
However where I can say 100% it saves time is discovery by answering these questions:
- At what state does bug X manifests?
- Explain how integration/feature works.
- I want to integrate with system X: Audit what items/features are used and what model changes are needed on my sideI at least give the new interns a stern warning: it is easy to speed yourself up by slowing others down if you pump a lot of slop.
It took about 4 days to get a production-ready reviewed code, while it took them 2-3 months to deliver something that another team judged "impossible to review".
The PR for the prototype was closed.
It helps that I'm a domain expert here, as I have a minor degree in the domain, so I can judge better. But the discrepancy is just too high to ignore.
Well that one's easy to answer, they're either A) lying, or B) working on the simplest possible software where this kind of stuff doesn't explode. Or the alternative 3rd option of what you mentioned, the initial pre-MVP phase goes decently but then it all collapses inevitably as the slop accumulates and the codebases become unmaintainable grey blobs, but that hardly matters to them because their MVP app never makes it past that initial stage before they jump ship to a new "amazing" idea.
The lying comes down to astroturfing and shilling from the LLM companies that want to sell people on the idea of vibecoding and tokenmaxxing.
Also, when people say 'read the code' do they really mean go line by line, or review the pseudo code? Meaning, read the high level architecture/data flow.
Because IMO the code matters very little if you have the proper testing environment and guardrails, the architecture always matters.
They blindly accept that LLMs "take time" after the slop grows because they're running several agents at the same time, so they can still claim to be productive.
Does it move the needle, business wise? Not really. But a lot of businesses are "optimising" for maximum token usage and for how many tasks one person can do, not for business value. Is it really surprising?
If code is expensive, you don't want to commit to a PoC unless you're damn sure. If dirty code is cheap, you can vibe code a PoC early, even if you aren't sure the project is viable. This, of course, leads to more projects dying in PoC phase. It also results in more projects that otherwise wouldn't have gotten to it getting past it.
Personally, I don't believe that "code is shitty and hard make changes in" is in any way, fashion or form an AI-exclusive problem. Big corporations had plenty of decade old codebases filled with decay and rot back in 2009 already. It's just the usual side effect of sacrificing "future maintainability" for "feature velocity" or "expertise" for "cheap labor".
Unlike the usual causes of code rot (cheap replaceable developers, outsourcing to India), AI might actually get out of the pit - by getting good enough at refactoring to be able to beat the code back into shape. There's nothing about refactoring in particular that demands a meatbag when the rest of the coding tasks don't.
The first is that having a single file with everything you have in mind is very useful. So I end up writing what the project is about, how the model is organized, what each button does, etc. This is good practice in general because writing down everything that the AI will have to consider forces you to consider edge cases before you program them. E.g. if you write "the detail pane shows the fields of the selected item," it makes you consider what should it show when there are no items, or if multiple selection is possible. As you can imagine, this file ends up a very long document even for a simple project because the goal is to pseudo-program everything and let the LLM translate it to an implementation.
Then it still gets things wrong about design, e.g. which pane goes left and which goes right, if you don't also provide an image that shows the layout.
And then, if you supply an exhausting amount of detail, the agent can generate more or less what you had in mind....... or rather, it can generate an OUTPUT that matches your specification from scratch.
The problem is that if there is something you failed to consider, and the AI makes an assumption there, you can end up with a fundamentally broken architecture that you will have to untangle yourself later. And at that point it's easier to write everything from scratch than to fix a pile of AI code that is based on a flawed design.
And it turns out that due to the "totem pole" way that software works, there are infinite places in code that a bad design decision can affect everything it touches.
A good example is how 2 components in a UI are bound to data. You can use events, a bus, state reactivity, etc. Personally I think the mediator pattern is the simplest way to handle GUIs. But an LLM is probably just going to use events for property bindings.
Welcome to the present.
Like many of us do not read the machine code generated by a C++ compiler, the code generated by an agent is similarly irrelevant and disposable, by now.
Reading a prompt but not reading the non-deterministic/non-reproducible LLM output is not comparable.
How do you know it does what you want it to do without reading it? Tests? How do you know what they test? Yes, clicking a button in a browser and getting the result you want satisfies most, but that only works on the most basic systems. Once a code base grows large enough, any one agent reading in its context wont understand the whole, and if no human does either, it becomes unworkable.
Isn't this exactly why OS projects are over-burdened by the firehose of contributions? The maintainers will want to read the code contributions, while those up-to-date with the latest models/agents/tools already trust their output to be above the average developer's (whatever that means in practice).
Edit: ...and that the source code is useful in retaining enough context of the problem being solved. So, most people will not store the prompts, trusting that the source code provides context for the next iteration.