This tasteless vibe-coded landing page makes me leave the webpage without even reading the first sentence.
How do you ever want to get customers with this?
Why not a simple plain background with some text explaining what it does. A simple pure HTML text website. Would catch the attention instead of invoking disgust.
The internet is full of people doing the “AI = compiler” comparison and it’s just wrong.
Maybe on a really small scale they can resemble a compiler because the number of possible outcomes is so small that it’s nearly deterministic.
But at any larger scale AI will not be deterministic anymore and at that point it will be relevant what the resulting code looks like. Because it can and will be slightly or very much off from your instruction.
If all inputs match a spec then why does it matter that the LLM is non-deterministic? I agree we might not be there yet, but the timelines for progress is shrinking and we are more likely to get there in a matter of months than not.
Had this eye-opening moment a few days ago where I enabled our company-wide MCP server and asked for a problem we noticed.
The agent looked through slack messages, logs from our devops portal, open telemetry traces and searched code snippets from other services through our RAG code search tool and created nice tables with timings, explanations and suggestion to fix it.
This is an amazing use of LLMs, contrary to offloading your thinking to it during implementation (which does not mean not using to write code but to actually understand the systems you are creating with it, and all their edge cases, inner workings etc.)
I really don’t want to see code generated by Claude without some constraint like rules in a Claude.md file. Even Fable on high is lazy enough to forget a ton of things that a senior engineer would not. For example tracing and handling all unhappy paths, not repeating code, not writing terrible doc strings, etc.
We are using quite a big list of rules and the output is significantly more aligned with what we interpret as “good” code.
There is no way that solely talking to an agent induces the same depth or amount of thinking than when you are actually writing for yourself. It just takes too much discipline to not offload your thinking.
And the discipline gets attacked even more when all you read is LLM text. For example in code reviews there is no noticeable value in answering LLM generated review comments. I remember taking great care answering human-written reviews comments with much thought to either further build on their suggestions or to forward knowledge about the system when I had to defend a particular change.
Now, some bot will read my carefully written response and forgets about it. There is no value anymore.
No wonder that our pull request comments feel like the dead internet theory right now.
I am absolutely pro AI assisted coding. But communication between humans HAS to stay human. I am currently experiencing the opposite and it’s bad.
Of course you can’t generalize this behavior to everyone. There will most certainly be people who can be disciplined and I try to be one of them.
But I don’t know where to draw the line yet. It’s difficult to decide what parts you are offloading and what parts you keep for your own brain. Because theoretically you can offload nearly everything when you get a well-defined ticket and just give it to an agent.
Maybe it’s also just me who is having a hard time staring at LLM generated texts all day and missing the past brainstorming, pair programming or “just talking about the project” sessions with colleagues and managers.
I fear that we are moving in the direction of silos again with lots of gate keeping as everyone has their own little rubber duck to talk to now.
Systems from today (if not worked on with discipline) will be no more than an agglomeration of features glued together. But as you said, guess our fight to fight will be to be that disciplined person.
> No wonder that our pull request comments feel like the dead internet theory right now.
This is the worst part of fully AI-generated code and automated reviews. It's so unnatural, and slightly anti-social, yet I can't figure out what the solution is when you have to ship features at the pace expected the average SWE nowadays.
Right? This one really hurts to see. I remember just a year ago we all used agents to help us code, but the end result of a session was still a human-made piece that other humans looked at and that we discussed about together.
And because we were talking to colleagues we wanted to make sure that we don’t waste their time. So we kept PR descriptions precise and understandable, we created small reviewable PRs and we wrote review comments that didn’t span half of your page.
Everything felt like it had value to someone.
But I agree with the current pace push it’s nearly impossible to do it any different. And honestly I don’t understand the rush. At least at our company I can’t discern any speed-up yet. Yes, more lines of code are written but features still take very long. It often just moves the work to a different stage in the process.
I am writing too much but I can’t stop thinking about all of this day and night. Sometimes even questioning whether the standards I want to live up to are maybe set too high for this day and age…
I think both can be true: as coding languages go from lower to higher level, they go from being more implementation-like (e.g. assembly, C) to being more spec-like (e.g. Rust, Haskell). It then follows that writing a good spec could be considered coding if your compiler (or agent) can reliably turn that spec into your desired output.
So the main challenge I see with this approach is getting the spec right. Too little detail and the output is uncontrolled, too much detail and you're adding too many constraints (and you may be better off just writing code). From my experience, agents haven't been the best at writing good specs. But maybe this project can help with that?
Yes. That’s the problem I noticed with specs too. Agents aren’t really good at finding the right abstraction layer. They tend to write way too detailed specs (e.g. naming variables in specs) and when controlling for less details the output degrades.
But I worry the most about who will be able to define all of those specs (with all of their necessary detail and edge cases etc.) without understanding the systems that live below the specs. Maybe that won’t be a problem anymore if agents will be able to 100% accurately translate specs into code. But for now I imagine this to be really difficult.
Two things about that. On the one hand, I couldn't believe coding would be replaced when I started Agent Smith in January 2026. On the other hand, I wanted proof.
After 500k lines of code in Agent Smith, none of which I wrote by hand, I have to admit it: coding is more or less solved. That doesn't mean architects, developers, DevOps people and everyone else aren't needed anymore. I think they're needed more than ever.
Just implementing something isn't good enough. The spec has to point to sensible approaches and procedures, and the code has to be well structured (in my view, at least). Then the specs can simply run in parallel all night.
So my actual work on Agent Smith isn't coding at all. It's deciding what the right thing to build is, and how, in terms of design and architecture. I don't even review the code. But I do test it: 10k tests, a harness, a commit hook that blocks a spec while the suite is red, the whole story.
And unfortunately, that works pretty well. I also think last year's programming was more romantic :-D
I agree that “coding” in the sense of hand-writing code is solved.
But code was made to create architecture, to design systems and also to make actual code (machine code) readable for humans.
In my experience with spec-driven development, the lossy layer of specs on top of code is not the right way to drive development of systems and architecture. The English language is not precise enough to describe those systems.
Of course you can use specs or just prompts to drive the creation of code (I do that for 99% of my code) but the “truth” is still the actual code and not the prompts/specs.
Maybe that’s also just a difference between people (like visual learners vs non-visual etc.) and some have an easier time to grasp every detail of the systems they are working on through code and some through descriptions.
Guess it also depends on the complexity of the software you are developing. For private projects I had more success with spec-driven while at work it would be a terrible choice.
I work as a freelancer and started programming at 12. I've been doing it for 40 years now.
I guess I'm ambivalent. On one hand these are crazy times, really stunning. Everything is changing, and AI takes over a lot of stuff I never wanted to do, but also parts of what I loved doing.
This year the time I spend actually programming dropped to 5–10%. Last year it was still 80%. That's a big change for a professional life. It means developers and architects spend their time on design and on proving the code works, not on writing it.
Agent Smith and all the other stuff is one of my side projects. So I'm just being a little nostalgic here, I guess. Nothing too serious ;-)
Do you know why it's easier to specify theorems than it is their proofs? Or why ACSL != C?
You can go ahead and make a more specific argument, e.g. that mainstream UX-centric software development may not be amenable to current paradigms of formal verification, but to insinuate that a complete spec reduces to source code itself is naive.
EDIT: Possibly I have responded too acutely to the points you care less about. I agree that "in the future we won't need programmers" is questionable since good spec-writing and spec-vetting requires at least as much expertise, if not more, than ordinary coding work, and that is fair to call comprehensive spec work "code" in that it is technical and formal. But it is decisively not source code.
That's a different thing. UML described structure: classes, relations, maybe some state machines. The generators turned that into skeletons, and people still wrote the actual logic by hand.
Here the agent writes the logic too, and 10k tests plus a commit gate check whether it works. In my case that's about 500k lines nobody typed. You can doubt that the approach generalizes, but it's not the same promise as UML.
reply