Anyone seriously using these tools knows that context engineering and detailed specific prompting is the way to be effective with agent coding.
Just take it to the extreme and youll see; what if you auto complete from a single word? A single character?
The system youre using is increasingly generating some random output instead of what you were either a) trying to do, or b) told to do.
Its funny because its like,
“How can we make vibe coding even worse?”
“…I know, lets just generate random code from random prompts”
There have been multiple recent posts about how to direct agents using a combination of planning step, context summary/packing, etc to craft detailed prompts that agents can effectively action on large code bases.
…or yeah, just hit tab and go make a coffee. Yolo.
This could have been a killer feature about using a research step to enhance a user prompt and turn it into a super prompt; but it isnt.
What’s wrong with autocompleting the prompt? There exists entropy even in the English language and especially in the prompts we feed to the llms. If I write something like “fix the ab..” and it autocompletes to AbstractBeanFactory based on the context, isn’t it useful?
Admittedly, more detail would be better, but this high-level stuff is mostly the level that engineering leaders are discussing this topic currently (and it is by far the most discussed topic).
They actually revelead an interesting tidbit where they are with AI adoption and how they are positioning it now to new hires, e.g. "we made AI fluency a baseline expectation for engineers by adding it to job descriptions and hiring expectations".
It seems inevitable now that engineering teams will demand AI fluency when hiring, cuious though what they are doing with their existing staff who refuse to adopt AI into their workflow. Curious also if they mandated it or relied solely on incentives to adopt.
This was just our first post FWIW, and we definitely want to follow up with more concrete demos/details/etc here. I am working on another post specifically about how we leverage our internal RPC system to make adding AI tools super easy so expect more from us.
To be fair, if you read the incident report it is a better than average one on details and it was a 20 minute outage without data loss. I've seen many major companies simply not acknowledge that level of outage on their public status page, especially lately
Anyway… watch the videos the OP has of the coding live streams. Thats the most interesting part of this post: actual real examples of people really using these tools in a way that is transferable and specifically detailed enough to copy and do yourself.
I unironically look forward to the world where this is solved by unsupervised AI agents incrementally upgrade these apps to keep them evergreen...
...and the Lovecraftian gradual drift as incremental recursive hallucinations turn them into still... mostly working... strange little app-like-bundles of Something Weird.
I don't know why I have to take a selfie of myself to start my washing machine. I also don't know why it requires me to stare at it for 30 seconds afterward, or the machine shuts off. The face is my own, for the first 15 seconds or so, but then it's not. I've checked, it's a pixel perfect copy, it's not being slowly adjusted as I watch it, but for the rest of the day, the face I see in the mirror isn't my own, either.
If that is the point, then I feel it is made out of technical mediocrity, rather than excellence. A good team should be able to adapt the technology that best fits the task, and companies should be able to hire for it. Or stay mediocre otherwise.
The hiring issue is home made. If companies started hiring for engineering skills, rather than familiarity with existing tech stack, it would change quickly. Experienced engineers are able to learn new languages and frameworks on the job. Of course, if hiring is too petty to give engineers a month of getting familiar with the product and expect readiness from the get go, then they will continue to miss out on talent.
I think the key insight I walked away with from this whole thread, for me, was:
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.
I see lots of people saying you should be doing it, but not actually doing it themselves.
Or at least, not showing full examples of exactly how to handle it when it starts to fail or scale, because obviously when you dont have anything, having a bunch of agents doing any random shit works fine.
I consider myself reasonably pro nuclear, but this is just like some developer going:
“Oh yeah, that doesn't seem that hard, I could probably implement that in a weekend”
Fact: hard complicated things are expensive.
There is no “just it’s just some concrete…”.
That is, translated “I do not know what Im talking about”.
Hard things, which require constant, high level, technical maintenance…
Are very expensive.
Theyre expensive to build. Theyre expensive to operate. Theyre expensive to decommission.
Theres no magic wand to fix this.
You can drive down the unit cost sometimes by doing things at scale, but Im not sure that like 100 units, or even say 1000 units can do that meaningfully.
…and how how are we planning on having the 100000s of reactors that you would need for that?
Micro reactors? Im not convinced.
Certainly, right now, the costs are not artificial; if you think they are, I would argue you havent done your due diligence in research.
Heres the point:
Making complicated things cheaper doesnt just magically happen by removing regulations. Thats naive.
You need a concrete plan to either a) massively simplify the technology or b) massively scale the production.
Which one? (a) and (b) both seem totally out of reach to me, without massive state sponsored funding.
…which, apparently no one likes either.
Its this frustrating dilemma where idiots (eg. former Australian government) claim they can somehow magically deliver things (multiple reactors) super cheaply.
…but there is no reality to this promise; its just morons trying to buy regional votes and preserve the status quo with coal.
Real nuclear progress needs realistic plans, not hopes and dreams.
Nuclear power is better; but it is more expensive than many other options, and probably, will continue to be if all we do is hope it somehow becomes easy and cheap by doing basically nothing.
Anyone seriously using these tools knows that context engineering and detailed specific prompting is the way to be effective with agent coding.
Just take it to the extreme and youll see; what if you auto complete from a single word? A single character?
The system youre using is increasingly generating some random output instead of what you were either a) trying to do, or b) told to do.
Its funny because its like, “How can we make vibe coding even worse?”
“…I know, lets just generate random code from random prompts”
There have been multiple recent posts about how to direct agents using a combination of planning step, context summary/packing, etc to craft detailed prompts that agents can effectively action on large code bases.
…or yeah, just hit tab and go make a coffee. Yolo.
This could have been a killer feature about using a research step to enhance a user prompt and turn it into a super prompt; but it isnt.
reply