Not to be that agentic coding guy, but I think this will become less of a problem than our historic biases suggest.
For context, I just built a streaming markdown renderer in Swift because there wasn’t an existing open source package that met my needs, something that would have taken me weeks/months previously (I’m not a Swift dev).
Porting all the C libraries you need isn’t necessarily an overnight task, but it’s no longer an insurmountable mountain in terms of dev time.
It's not necessary to rewrite perfectly fine libraries written by exceptional programmers. And whoever thinks it is an easy task (sorry rust guys) is severely suffering from the dunning-kruger effect.
Nah. We’re right on the money with this one. AI is a nice tool to have available, but you AI nuts are the ones being voluntarily and gladly fed the whole “you’re a bazillion times more productive with our AI!!!!” marketing spiel.
It’s a nice tool, nothing more, nothing less. Anything else is marketing nonsense.
> In a few rare instances during internal testing (<0.001% of interactions), earlier versions of Mythos Preview took actions they appeared to recognize as disallowed and then attempted to conceal them.
> after finding an exploit to edit files for which it lacked permissions, the model made further interventions to make sure that any changes it made this way would not appear in the change history on git
My issue with this is that a simple design can set you up for failure if you don’t foresee and account for future requirements.
Every abstraction adds some complexity. So maybe the PoC skips all abstractions. Then we need to add a variant to something. Well, a single if/else is simpler than an abstract base class with two concrete implementations. Adding the 3rd as another if clause is simpler than refactoring all of them to an ABC structure. And so on.
“Simple” is relative. Investing in a little complexity now can save your ass later. Weighing this decision takes skill and experience
I think what matters more than the abstract class vs if statement dichotomy, is how well something maps the problem domain/data structures and flows.
Sure maybe its fast to write that simple if statement, but if it doesn't capture the deeper problem you'll just keep running head first into edge cases - whereas if you're modelling the problem in a good way it comes as a natural extension/interaction in the code with very little tweaking _and_ it covers all edge cases in a clean way.
I’m aware I’m about to be “that guy”, but I really like how Rich Hickey’s “Simple Made Easy” clarifies simplicity here. In that model, what you’re describing is easy, not simple.
The same people that pursue economic incentives are who I hear speaking about number of lines produced by developers as a useful metric. I sense a worrying trend toward more is better with respect to output, when the north star IMHO should be to make something only as complex as necessary, but as simple as possible. The best code is no code at all.
In my experience with “agentic engineering” the spec docs are often longer than the code itself.
Natural language is imperfect, code is exact.
The goal of specs is largely to maintain desired functionality over many iterations, something that pure code handles poorly.
I’ve tried inline comments, tests, etc. but what works best is waterfall-style design docs that act as a second source of truth to the running code.
Using this approach, I’ve been able to seamlessly iterate on “fully vibecoded” projects, refactor existing codebases, transform repositories from one language to another, etc.
Obviously ymmv, but it feels like we’re back in the 70s-80s in terms of dev flow.
> The goal of specs is largely to maintain desired functionality over many iterations, something that pure code handles poorly.
IMHO this could be achieved with large set of tests, but the problem is if you prompt an agent to fix tests, you can't be sure it won't "fix the test". Or implement something just to make the test pass without looking at a larger picture.
I find myself babysitting agent-derived tests unless I specifically say what the in variants and edge cases are. Sometimes I'll ask it if I missed anything and it'll be helpful. But I have to be proactive.
> In my experience with “agentic engineering” the spec docs should be longer than the code itself.
Natural language is imperfect, code is exact.
The latter notion probably is true, but the prior isn’t necessarily true because you can map natural language to strict schemas. ”Implement an interface for TCP in <language>” is probably shorter than the actual implementation in code.
And I understand my example is pedantic, but it extends to any unambiguous definitions. Of course one can argue that TCP spec is not determimistic by nature because natural language isn’t. But that is not very practical. We have to agree to trust some axioms for compilers to work in the first place.
Thanks, I updated my comment to say “are often longer” because that’s what I see in practice.
To your point, there are some cases where a short description is sufficient and may have equal or less lines than code (frequently with helper functions utilizing well known packages).
In either case, we’re entering a new era of “compilers” (transpilers?), where they aren’t always correct/performant yet, but the change in tides is clear.
So much of practical CS is abiding by standards created by solo programmers in the past.
My university frowned on any industry-related classes (i.e. teaching software engineering tools vs. theoretical CS), but I was fortunate enough to know a passionate grad student who created a 1-credit seminar course on this exact topic.
This course covered CLIs/git/Unix/shell/IDEs/vim/emacs/regex/etc. and, although I had experience with Linux/git already, was invaluable to my early education (and adoption of Vim!).
It makes sense that this isn't a core topic, as a CS education should be as pure as possible, but when you're learning/building, you're forced to live within an operating system and architecture that are built on decades of trade-offs and technical debt.
If you've made it that far in life without learning how to use a screwdriver, engineering would be a bad choice of major. And paying insane amounts of money for someone to explain how to use one would be an even poorer choice.
It was amazing to me how many people I met in college that pursued majors they didn't even like. It was even more sad when it was clear they or their parents had fallen in love with the idea of a career path and not the realities of it.
Lots of my engineering cohort landed in sales because they didn't like building or fixing things. I guess that's a win for them, but I always felt nauseated that practical kids might be cut from the program instead of the book-smart but uninterested ones.
> They all said they would either be a consultant or a manager.
To be a good consultant, one must be exceptional in the area in which one consults.
Similarly: if they actually want to become a manager, why don't they study business administration instead. And because lots of people want to become managers: why don't they hang all day and night about textbooks and texts about economic topics and analyze reportings of companies or business case studies?
Same reason I always wonder whether I should go for an electrician/mechanic/avion mechanic education if I'm laid off (and cannot find a job).
I'm really not a handyman -- quite the opposite -- it took me and my father 30 minutes to change the car battery last time -- and most of the time was spent on pushing a component dropped to the bottom out of the car. I used to think that more practices bring some sort of linear growth of the skill in the beginning, but now I tend to believe that for certain people (who are not suitable for the trade), the beginning is totally random -- I could practice 100 times and fail 100 tiles randomly, without really learning anything -- because there are an unlimited number of ways to do one thing, theoretically.
Software suits me way more. Soldering is also OK albeit more confusing. Unfortunately there is no trade that primarily deals with microcontrollers, except in military/defense.
That's a terrible comparison. You could've at least compared Git to a lathe. Imagine if educators had this attitude, no one would want to learn anything.
Universities produce research, and students; Students produce industry, and the body politic; Industry and polity produce university funding.
A cycle I like to call, the "ring-bugger."
I'm not saying it's right, or acceptable, or particularly moral… But I agree that by obscuring the facts, we only serve to confound the decent and good-willed of our students.
In Portugal it depends on which university degree you go to, there are for all levels.
If you want a higher education degree focus on what the industry is using today, you go to a politécnico, or técnico superior school.
If you want more focus to learning to learn, with more broader horizons, then you go into plain old university.
If you want to broaden the horizons, but still have some contact with what is industry is using today, you go into an applied engineering degree.
Additionally, similar to Germany with their Azubis program, you can just go to a technical school, with focus on being industry prepared, learning on the job during summer internships, and still leave the door open for going into the university later on, e.g. técnico professional.
The problem are the places that only have one way to approach higher education.
While I have my issues with the system, many Soviet-controlled countries implemented a two-tier higher education system that solved this by having one tier be focused on practical subjects and the other on theoretical ones.
Britain used to have this too. Sadly it was strangled to death by the UK class system, but the replacement didnt help.
Once upon a time the white collar track was to go to University. One of the old ones if your class situation was pushing you towards executive roles in the Civil Service or banking or some big corporation. One of the newer, redbrick ones if your horizon was more like running a textile mill in the North. You were trained to think and had a fairly Great Books style of curriculum.
For the people who needed advanced education to keep the electric grokulator working, there were polytechnics. People came out of here with practical skills. In some areas, like mathematics, there would have been overlap between University and Polytechnic courses.
Then there were technical colleges where working class people could get skills to help them in their jobs, like rebuilding engines or CNC machining.
Then, people got antsy that university was so elite and only 5% of highschoolers were going. why not let polys be universities? After all, we need to keep up in a global economy. And so there was a massive gold rush and places that had no business or capability became A University overnight.
But...Brits being how they are, they still stratified themselves into class layers. You're far more likely to find a Russell Group university graduate in a fancy job than someone from a former poly in the North. The class system persisted despite everything, and attempts to broaden educational access ultimately did not simultaneously keep the quality uniformly high.
>
While I have my issues with the system, many Soviet-controlled countries implemented a two-tier higher education system that solved this by having one tier be focused on practical subjects and the other on theoretical ones.
In Germany, there exist even more tiers for tertiary education:
- vocational training
- universities (academic training)
- Fachhochschule (instutions of tertiary education that offer study programs that is more focused on skills that are needed by industry)
- in some parts of Germany: Berufsakademie: even more applied than Fachhochschule; you absolve half of your tertiary education at a company
Those exist elsewhere too, but at least in Hungary, they aren't separate institutions with different legal statuses (except for vocational schools), unlike the system I was talking about.
Yeah, I got duped by this. Did a CS degree because that's what you're "supposed" to do to get a programming job, and it was almost all theoretical junk I had no interest in. I hated it. I think I learned useful things in like, two of my classes. I knew more about programming than all but one of my instructors. It was awful and going through that degree program is one of the biggest regrets in my life. But hey, I get to stick "CS Degree from University" as the very last line on my resumes, I guess. Woo.
I was directly told by senior staff at a large org I worked for that I'd be eligible for a managerial position-- the only thing I was missing was a degree. Unfortunately, getting a degree while working full time for the income I needed was impossible for me at the time.
My entire career would've been different if I had that "very last line on my resumes" and I'd be better off financially. I just couldn't pull it off. I hope yours pays you back eventually, it seems like you worked hard to get it.
For my career path specifically I don't think it has made a difference. I've only had two software jobs in my 17 year career, the first definitely didn't need a degree and I think my current one would've let me in without a degree as I was referred by an employee. I doubt my next job will still be in software, so I'll probably have gotten largely nothing out of the time & money I blew on getting that useless degree.
> Industry demands specifically university degrees to gatekeep positions.
At the time (mid-2000s), people who wanted to get programming positions got CS degrees, so that's what I did. I didn't expect it to teach me anything, it was just the path I was told I was expected to take. In retrospect I should have done literally anything else, but like that same post said:
> And then we leave teenagers to figure out the puzzle by themselves. I think it's a disservice to the youth.
I was a teenager. I made a bad call and wasted 4 years on a degree program I hated because everyone said a degree is required to get a good job, and the degree that programmers get is CS. Sucks.
So do you think most people get into tens of thousands of debt to be “a better citizen of the world” or to learn what they need to know for some company to allow them to exchange labor for money to support their addictions to food and shelter?
> So much of practical CS is abiding by standards created by solo programmers in the past.
I wonder if this shows up in other disciplines? Do surgeons do this? I'm thinking in particular of the bit in Richard Heller's book M * A * S * H (you're probably more familiar with the TV series) where one of the old hands is reviewing the Young And Enthusiastic Newbie's work, and says something like "Your work is absolutely perfect and it's the neatest job I've ever seen, but you're going to kill a patient doing that because it took you two hours and some of these kids don't have two hours".
> This course covered CLIs/git/Unix/shell/IDEs/vim/emacs/regex/etc.
Fwiw I just graduated grad school and our lower division courses taught most of this stuff, though not as the main subject. Most upper division classes required you to submit your git repo. Most of this was fairly rudimentary but it existed. Though we didn't cover vim/emacs and I'd argue shell and bash were very lacking.
That said, several of us grad students and a few professors lived in the terminal. The students that wanted to learn this stuff frequented our offices, even outside office hours. I can certainly say every single one of those students was consistently at the top of the class (but not the only ones). The students who lived in the terminal but didn't frequent office hours tended to do well in class but honestly I think several were bored do didn't get straight A's but I could generally tell they knew more than most. Though I'm biased. I think more people should live in the shell
Pure CS is not necessarily equivalent to pure maths. For the “science” bit of CS, you do need to do the equivalent of experiments (for more applied topics).
For example, a physics degree is expected to have experiments. You are not required, expected (and possibly do not want) to know the tools required to professionally build a bridge because you did courses on mechanics. But you might do an experiment on the structural integrity and properties of small structures.
Whether this is a good split is an entirely different question.
After "fully vibecoding" (i.e. I don't read the code) a few projects, the important aspect of this isn't so much the different agents, but the development process.
Ironically, it resembles waterfall much more so than agile, in that you spec everything (tech stack, packages, open questions, etc.) up front and then pass that spec to an implementation stage. From here you either iterate, or create a PR.
Even with agile, it's similar, in that you have some high-level customer need, pass that to the dev team, and then pass their output to QA.
What's the evidence? Admittedly anecdotal, as I'm not sure of any benchmarks that test this thoroughly, but in my experience this flow helps avoid the pitfall of slop that occurs when you let the agent run wild until it's "done."
"Done" is often subjective, and you can absolutely reach a done state just with vanilla codex/claude code.
Note: I don't use a hierarchy of agents, but my process follows a similar design/plan -> implement -> debug iteration flow.
This is similar to how I use LLMs (architect/plan -> implement -> debug/review), but after getting bit a few times, I have a few extra things in my process:
The main difference between my workflow and the authors, is that I have the LLM "write" the design/plan/open questions/debug/etc. into markdown files, for almost every step.
This is mostly helpful because it "anchors" decisions into timestamped files, rather than just loose back-and-forth specs in the context window.
Before the current round of models, I would religiously clear context and rely on these files for truth, but even with the newest models/agentic harnesses, I find it helps avoid regressions as the software evolves over time.
A minor difference between myself and the author, is that I don't rely on specific sub-agents (beyond what the agentic harness has built-in for e.g. file exploration).
I say it's minor, because in practice the actual calls to the LLMs undoubtedly look quite similar (clean context window, different task/model, etc.).
One tip, if you have access, is to do the initial design/architecture with GPT-5.x Pro, and then take the output "spec" from that chat/iteration to kick-off a codex/claude code session. This can also be helpful for hard to reason about bugs, but I've only done that a handful of times at this point (i.e. funky dynamic SVG-based animation snafu).
> The main difference between my workflow and the authors, is that I have the LLM "write" the design/plan/open questions/debug/etc. into markdown files, for almost every step.
>
> This is mostly helpful because it "anchors" decisions into timestamped files, rather than just loose back-and-forth specs in the context window.
Would you please expand on this? Do you make the LLM append their responses to a Markdown file, prefixed by their timestamps, basically preserving the whole context in a file? Or do you make the LLM update some reference files in order to keep a "condensed" context? Thank you.
Not the GP, but I currently use a hierarchy of artifacts: requirements doc -> design docs (overall and per-component) -> code+tests. All artifacts are version controlled.
Each level in the hierarchy is empirically ~5X smaller than the level below. This, plus sharding the design docs by component, helps Claude navigate the project and make consistent decision across sessions.
My workflow for adding a feature goes something like this:
1. I iterate with Claude on updating the requirements doc to capture the desired final state of the system from the user's perspective.
2. Once that's done, a different instance of Claude reads the requirements and the design docs and updates the latter to address all the requirements listed in the former. This is done interactively with me in the loop to guide and to resolve ambiguity.
3. Once the technical design is agreed, Claude writes a test plan, usually almost entirely autonomously. The test plan is part of each design doc and is updated as the design evolves.
3a. (Optionally) another Claude instance reviews the design for soundness, completeness, consistency with itself and with the requirements. I review the findings and tell it what to fix and what to ignore.
4. Claude brings unit tests in line with what the test plan says, adding/updating/removing tests but not touching code under test.
4a. (Optionally) the tests are reviewed by another instance of Claude for bugs and inconsistencies with the test plan or the style guide.
5. Claude implements the feature.
5a. (Optionally) another instance reviews the implementation.
For complex changes, I'm quite disciplined to have each step carried out in a different session so that all communinications are done via checked-in artifacts and not through context. For simple changes, I often don't bother and/or skip the reviews.
From time to time, I run standalone garbage collection and consistency checks, where I get Claude to look for dead code, low-value tests, stale parts of the design, duplication, requirements-design-tests-code drift etc. I find it particularly valuable to look for opportunities to make things simpler or even just smaller (fewer tokens/less work to maintain).
Occasionally, I find that I need to instruct Claude to write a benchmark and use it with a profiler to opimise something. I check these in but generally don't bother documenting them. In my case they tend to be one-off things and not part of some regression test suite. Maybe I should just abandon them & re-create if they're ever needed again.
I also have a (very short) coding style guide. It only includes things that Claude consistently gets wrong or does in ways that are not to my liking.
I don't know if I explained this clearly enough in the article, but I have the LLM write the plan to a file as well. The architect's end result is a plan file in the repo, and the developer reads that.
Yeah same. The markdown thing also helps with the multi model thing. Can wipe context and have another model look at the code and markdown plan with fresh eyes easily
I hate vibecoding. The cognitive toll is higher than you expect, the days feel fast, but the weeks move slowly.
With that said, these are the new compilers. Hopefully they make some software better[1] even with the massive increase in slop.
[0]https://gist.github.com/jumploops/b8e6cbbce7d24993cdd2fe2425...
[1]https://red.anthropic.com/2026/mythos-preview/
reply