201–210 of 250 posts
Earlier quoted context omitted.
Using these tools comes down to basically just writing what you want in a natural language. I don't think it will be a problem to catch up if they need to.
Context management, plan mode versus agent mode, skills vs system prompt, all make a huge difference and all take some time to build intuition around. Not all that hard to learn, but waiting for things to settle down assumes things are going to settle down. Are they? When?
The real insight buried in here is "build what programmers love and everyone will follow." If every user has an agent that can write code against your product, your API docs become your actual product. That's a massive shift.
We're already seeing this with search. Ask an LLM "what tools do X" and the answer depends heavily on structured data, citation patterns, and how well your docs/content map to the LLM's training. Companies with great API docs but zero presence in the training data just won't exist to these agents.
So it's not just "API docs = product" -- it's more like "machine-legible presence = existence." Which is a weird new SEO-like discipline that barely has a name yet.
Earlier quoted context omitted.
I'm very much looking forward to this shift. It is SO MUCH more pro-consumer than the existing SaaS model. Right now every app feels like a walled garden, with broken UX, constant redesigns, enormous amounts of telemetry and user manipulation. It feels like every time I ask for programmatic access to SaaS tools in order to simplify a workflow, I get stuck in endless meetings with product managers trying to "understan…
> Right now every app feels like a walled garden, with broken UX, constant redesigns, enormous amounts of telemetry and user manipulation OK, but: that's an economic situation. > so much less scope for engagement-hacking, dark patterns, useless upselling, and so on. Right, so there's less profit in it. To me it seems this will make the market more adversarial, not less. Increasing amounts of effort will be expended t…
it's basically SEO all over again but worse, because the attack surface is the user's own decision-making proxy. at least with google you could see the search results and decide yourself. when your agent just picks a vendor for you based on what it "found," the incentive to manipulate that process is enormous.
we're going to need something like a trust layer between agents and the services they interact with. otherwise it's just an arms race between agent-facing dark patterns and whatever defenses the model providers build in.
I agree with his assessment up until this point in time, it is where we currently are. But it seems to me there is still a large chunk of engineers who don't extrapolate capability out to the engineer being taken out of the loop completely. Imo, it happens in fairly short order. 2-3 years.
I have no problem with experienced senior devs using agents to write good code faster. What I have a problem with is inexperienced "vibecoders" who don't care to learn and instead use agents to write awful buggy code that will make the product harder to build on even for the agents. It used to be that lack of a basic understanding of the system was a barrier for people, but now it's not, so we're flooded with code wr…
the number of experienced, senior programmers though, who are in “anti-LLM” camp, is still fairly staggering.
Earlier quoted context omitted.
I'm very much looking forward to this shift. It is SO MUCH more pro-consumer than the existing SaaS model. Right now every app feels like a walled garden, with broken UX, constant redesigns, enormous amounts of telemetry and user manipulation. It feels like every time I ask for programmatic access to SaaS tools in order to simplify a workflow, I get stuck in endless meetings with product managers trying to "understan…
> Right now every app feels like a walled garden, with broken UX, constant redesigns, enormous amounts of telemetry and user manipulation OK, but: that's an economic situation. > so much less scope for engagement-hacking, dark patterns, useless upselling, and so on. Right, so there's less profit in it. To me it seems this will make the market more adversarial, not less. Increasing amounts of effort will be expended t…
Earlier quoted context omitted.
Ok, I’ll bite. What’s there to learn that you can tie directly to an increase of productivity? I can say “learn how to use vim makeprg feature so that you can jump directly to errors reported by the build and tool” and it’s very clear where the ROI. But all the AI hypers are selling are hope, prayers, and rituals.
The skill is learning to supply the LLM with enough context to do anything a developer does: turn specs into code, check its work including generating and running tests, debug and analyze the code for faults or errors, and run these in a loop to converge on a solution. If you're about to do something by hand in an IDE, STOP. Think about what the LLM will need to know to perform that task for you. It may take some hum…
> This puts in reach the ability to try things you wouldn't countenance otherwise due to the effort and tedium involved.
If you’re talking about prototypes, a whiteboard is way cheaper and less time consuming than an agent.
> I deeply appreciate hand-tool carpentry and mastery of the art, but people need houses and framing teams should obviously have skillsaws. Where are all the new houses? I admit I am not a bleeding edge seeker when it comes to software consumption, but surely a 10x increase in the industry output would be noticeable to anyone?
Org processes have not changed. Lots of the devs I know are enjoying the speedup on mundane work, consuming it as a temporary lifestyle surplus until everything else catches up. You can't saw faster than the wood arrives. Also the layout of the whole job site is now wrong and the council approvals were the actual bottleneck to how many houses could be built in the first place... :/
If I may hijack your analogy, it would be like if all the construction crews got really fast at their work, so much so that the city decided to go for an “iterative construction” strategy because, in isolation, the cost of one team trying different designs on-site until they hit on one they liked became very small compared to the cost of getting city planners and civil engineers involved up-front. But what wasn’t considered was the rework multiplier effect that comes into play when the people building the water, sewage, electricity, telephones, roads, etc. are all repeatedly tweaking designs with minimal coordination amongst each other. So then those tweaks keep inducing additional design tweaks and rework on adjacent contractors because none of these design changes happen in a vacuum. Next thing you know all the houses are built but now need to be rewired because the electricity panel is designed for a different mains voltage from the drop and also it’s in the wrong part of the house because of a late change from overhead lines in the alleys to underground lines below the street.
Many have observed that coding agents lack object permanence so keeping them on a coherent plan requires giving them such a thoroughly documented plan up front. It actually has me wondering if optimal coding agent usage at scale resembles something of a return to waterfall (probably in more of a Royce sense than the bogeyman agile evangelists derived from the original idea) where the humans on the team mostly spend their time banging out systems specifications and testing protocols, and iteration on the spec becomes somewhat more removed from implementing it than it is in typical practice nowadays.
Earlier quoted context omitted.
Yes we do, you don't just start a brand new web project and spit out CORS rules, authentication schemes, roles, etc in one sitting do you? Are you an AI?
Yes I really do, because this has been a solved problem for a while. Also it’s necessary to get right because retro fitting it later is a pain.